- Create a formula field called Expected Name with a formula that evaluates to the name you want to see.
- Create a validation rule called "Name Expected" with error formula:
Name != Expected_Name__c
Monday, December 13, 2010
Enforcing Record Name Convention in Salesforce without Apex
One can enforce a record naming convention with a few steps in Salesforce, sans Apex!
Labels:
convention,
enforce,
formula,
record name,
Salesforce,
validation rule
Enforcing Record Name Uniqueness in Salesforce without Apex
I discovered today that it is possible to enforce record name uniqueness in Salesforce without using any Apex code!
All that is needed is a simple validation rule with the error formula set to the following:
However, there doesn't seem to be an easy to to perform a case-sensitive comparison in the formula builder. Another thought would be to do the following to enforce name uniqueness:
Last edited on 8/10/2011.
All that is needed is a simple validation rule with the error formula set to the following:
Name = VLOOKUP( $ObjectType.Object.Fields.Name , $ObjectType.Object.Fields.Name , Name ) && Id <> VLOOKUP( $ObjectType.Object.Fields.Id , $ObjectType.Object.Fields.Name , Name )However, there doesn't seem to be an easy to to perform a case-sensitive comparison in the formula builder. Another thought would be to do the following to enforce name uniqueness:
- Create a text field called Unique Name on the object, and add the case-sensitive uniqueness constraint.
- Create a workflow field update called Unique Name that just sets
Unique_Name__ctoName. - Create a workflow rule called Set Unique Name that's triggered every time a record is created or updated.
- Activate the workflow rule.
Last edited on 8/10/2011.
Labels:
enforce,
formula,
record name,
Salesforce,
unique,
validation rule
Friday, December 10, 2010
Field Update in Before Trigger Propagates to After Trigger
I confirmed a simple fact in version 20.0 Apex triggers today, that will guide me when writing future trigger code.
If a lookup field is not specified in the DML operation and will not be populated via any other non-trigger means, then a
System.debug(Trigger.new); will show that the trigger does not have access to the lookup field value.However, if the lookup field is populated or updated in the before trigger, then the after trigger will be able to access the new value!
For example, I have a Campaign Feed object that has a Lookup(Campaign) field with an API name of
Campaign__c. In my before insert trigger on Campaign_Feed__c, I set Campaign__c to the Id of a newly created Campaign. As a result I am able to then use Campaign__c in my after insert trigger, even though I didn't initially specify a Campaign__c value when inserting the Campaign Feed record.Wednesday, November 10, 2010
NO-SOFTWARE Tutorial for Salesforce Web Services
First... the gripes against Salesforce. Please feel free to open the actual tutorial if you're not interested in reading about how a billion-dollar company published an API with a lack of documentation that would induce balding in even a teenage developer.
16 man-hours of angst and frustration with Salesforce finally yielded a fruit that I can eat and then sleep on. Who would've thought that Salesforce, in its infinite wisdom, with its "NO SOFTWARE" slogan, would overlook the need for a tutorial that shows how to use the Salesforce WSDL in conjunction with the Web Services API. I certainly didn't expect this lack of documentation and support (which is Premier Support in my case).
As a newbie who has never touched a web service before with an immediate and urgent need to call one from my Salesforce org, I had no idea where to begin. Furthermore, my hopes were dashed when I discovered that the Quick Start chapter in the Web Services API Developer's Guide used Apache Axis or Microsoft Visual Studio as an integral part of the tutorial. What happened to "NO SOFTWARE"? Doesn't the Salesforce platform support both inbound messages and outbound messages for web services?
My chagrin was further exacerbated when I discovered to my extreme disappointment that neither the Salesforce-generated Enterprise WSDL nor the Partner WSDL could be directly imported back into Salesforce using the Generate from WSDL feature for Apex classes. Now, where have I encountered a very similar irony... Oh, yeah! I wrote about it in a previous post, "Salesforce CSV Format for Report Exports Is Not IETF RFC 4180-compliant".
Needless to say, when I thought that my first foray into web services would be made less painful by using Salesforce as the learning platform, I thought very, very wrongly. Well, I shouldn't say that, since the experience could've been worse if I had to write two web services from scratch in Java or something.
Anyway, thanks to an abundance of hope and the following inspirations found on the Internet, I believe I now have a workable tutorial that newbies like myself can use to familiarize themselves with using web services in Salesforce.
JavaRanchForce.com Discussion Boards
If this tutorial helps even one person, I will consider the 16 hours well spent.
Labels:
Apex,
API,
hello,
Salesforce,
SOAP,
tutorial,
web service,
world,
WSDL
Thursday, October 21, 2010
Default Status for Emails Synced through Salesforce for Outlook
The default Status value that is assigned to emails synced via Salesforce for Outlook is not the oldest Status value, but rather the first Status value on the list that marks an Activity as Completed.
For example, the Status picklist had the following options:
To fix this problem, all I have to do is reorder the picklist so that "Completed" comes before "Completed through another activity". There is no need to delete any picklist options and then recreate them.
For example, the Status picklist had the following options:
- Not Started
- In Progress
- Completed
- Not Started
- In Progress
- Completed through another activity
- Completed
To fix this problem, all I have to do is reorder the picklist so that "Completed" comes before "Completed through another activity". There is no need to delete any picklist options and then recreate them.
Wednesday, October 20, 2010
IETF RFC 4180-compliant CSV Reader for Salesforce
After several failed attempts at creating an IETF RFC 4180-compliant CSV reader for Salesforce, I finally have a candidate of an Apex Class that may be able to fit the bill for reading a compliant CSV file and returning a nested
Edit
Posting the code within a PRE tag did not work. Let's try this download link instead.
List where the outer List contains row records, and the inner List contains the sequential values in that row.Edit
Posting the code within a PRE tag did not work. Let's try this download link instead.
Labels:
4180,
Apex,
CSV,
IETF,
Knowledgebase,
parser,
reader,
RFC,
Salesforce
Tuesday, August 24, 2010
Passing Data between Visualforce Pages with Controllers and Extensions
I spent a fair amount of time yesterday trying to figure out how to pass information back and forth between Visualforce pages, despite finding a pretty good article in the Force.com IDE Library.
"Creating a Wizard with Visualforce Pages"
http://www.salesforce.com/us/developer/docs/cookbook/Content/vf_wizard.htm
The article got me started, but then when I moved to the actual implementation in which I wanted to use controller extensions, I would be able to pass data between pages until I started including the extensions. I was left scratching away at my head for a while.
Finally, after many trials and errors, I came to the following conclusion: In order for data to be maintained from page to page, both the controller and the extension(s) referenced must be the same across all pages in the group.
For example, assume that the following Apex classes exist:
Also assume that I am trying to pass data between the following two pages, each of which uses the functionality included in the corresponding extension:
If I specify different attributes
This is a bit depressing to know, but at least now I have a framework within I can build my actual application.
"Creating a Wizard with Visualforce Pages"
http://www.salesforce.com/us/developer/docs/cookbook/Content/vf_wizard.htm
The article got me started, but then when I moved to the actual implementation in which I wanted to use controller extensions, I would be able to pass data between pages until I started including the extensions. I was left scratching away at my head for a while.
Finally, after many trials and errors, I came to the following conclusion: In order for data to be maintained from page to page, both the controller and the extension(s) referenced must be the same across all pages in the group.
For example, assume that the following Apex classes exist:
MyControllerMyPage1ExtMyPage2Ext
Also assume that I am trying to pass data between the following two pages, each of which uses the functionality included in the corresponding extension:
- MyPage1
- MyPage2
If I specify different attributes
extensions="MyPage1Ext" and extensions="MyPage2Ext" for the two pages, then I am unable to pass data back and forth even if I specify the same controller. The trick is to use the same controller and the same extensions on both pages via the attribute extensions="MyPage1Ext,MyPage2Ext".This is a bit depressing to know, but at least now I have a framework within I can build my actual application.
Labels:
controller,
extension,
Knowledgebase,
Salesforce,
Visualforce,
wizard
Subscribe to:
Posts (Atom)
