Apex Code Development You need to sign in to do that
Don't have an account?
StrangeRoutines Using RecordType in a formula
[I posted this on the formulas board, didn't get a response. So I am reposting it here since, as I am a newbie, this might be a newbie question!]
I need to open a VisualForce page based on the value of a RecordType in a custom object. For maintainability, it seemed like the easiest thing was to map the RecordType string to the VFpage name by dropping illegal characters like ampersands, etc. For instance, if the RecordType was "Flood/Fire Damage" then the page name would be "floodfiredamage". So I coded a URL for a custom detail button like this (the custom object is Quote__c):
/apex/{!CASE(Quote__c.RecordType,"Flood/Fire Damage","FloodFireDamage","")}?ID={!Quote__c.Id}
(In the real situation, there would be many value/result pairs in the CASE statement, only one is shown here for simplicity.) To my surprise it did not work. After flailing around for a while I coded up the following URL and VFpage to demonstrate the problem (I am using the UPPER function as a simple example of calling a function with a RecordType. The ID parameter and standardController are unnecessary for this test):
URL on custom button:
/apex/testpage?ID={!Quote__c.Id}¶m1={!Quote__c.RecordType}¶m2={!UPPER( Quote__c.RecordType)}
VFpage TestPage contents:
<apex:page standardController="Quote__c">
<p>id={!$Currentpage.parameters.id}</p>
<p>param1={!$Currentpage.parameters.param1}</p>
<p>param2={!$Currentpage.parameters.param2}</p>
</apex:page>
And here is the result when I click the button to invoke TestPage:
id=a0750000005PHAf
param1=Employers Liability
param2=01250000000QHEY
When used directly, RecordType seems to behave as expected. But, when put inside a function the internal id is passed to the function rather than the string. How do I get it to pass its string value to a function?
Any help would be deeply appreciated!
Hi,
This is happening as salesforce displays the recordtype name but internally stores the recordtype id, the workaround would be to store the record type name in a formula field or in a normal text field using workflow rule. Then instead of - Quote__c.RecordType use the new text field or formula field which you will be creating to store the record type name.
Did this answer your question? If not, let me know what didn't work, or if so, please mark it solved.
Hi,
you can use URLENCODE(str_url) function which will generate correct URL without any wild characters
then you can access this params in controller
Thanks,
Bala
I thought about that and it would suffice if the mapping function simply needed to squeeze out wild characters (and indeed that is how I posed the original problem.) However, in the final implementation there is a sizable possibility that the mapping may be more complex and involve different inputs resulting in the same output, e.g., RecordTypes "X 1", "X 2", and "Y Z" all being tied to a VFPage called "X". The only way to cleanly handle that is with a CASE statement and I didn't want to set up the URLENCODE only to have to rip it out later and replace it with a CASE.
(This is a response to message #2, I have no idea why it appears here, in the wrong place!)
My concern here is the apparent inconsistent, and undocumented, treatment of RecordType. When you have a lookup field, which is what RecordType basically is, you are given two choices for the merge field in the formula builder: the id, or the looked-up value. For instance, if a child has a lookup to a parent called Product, then the merge fields available are Product__c and ProductId__c. In the same way, RecordType is available in the formula builder in two flavors, RecordType and RecordTypeId, yet they are not treated like other stored ID fields in URL processing.
If I expand my original example to 4 parameters, i.e., a VFPage like this:
<apex:page standardController="Quote__c">
<p>ID={!$CurrentPage.parameters.id}</p>
<p>Param1={!$CurrentPage.parameters.param1}</p>
<p>Param2={!$CurrentPage.parameters.param2}</p>
<p>Param3={!$CurrentPage.parameters.param3}</p>
<p>Param4={!$CurrentPage.parameters.param4}</p>
</apex:page>
and a URL of this:
/apex/TestParamPage?id={!Quote__c.Id}¶m1={!Quote__c.ProductId__c}¶m2={!UPPER( Quote__c.ProductId__c )}¶m3={!Quote__c.Product__c}&Param4={!UPPER( Quote__c.Product__c )}
I get this on invocation of the page:
ID=a0750000005PE6b
Param1=a0K50000002pq3G
Param2=A0K50000002PQ3G
Param3=General Product 21
Param4=GENERAL PRODUCT 21
This result is reasonable, I get an Id where I specified it and a looked-up string also per spec. However, if I use RecordType in the same exact way in a URL spec:
/apex/TestParamPage?id={!Quote__c.Id}¶m1={!Quote__c.RecordTypeId}¶m2={!UPPER( Quote__c.RecordTypeId )}¶m3={!Quote__c.RecordType}&Param4={!UPPER( Quote__c.RecordType )}
I get:
ID=a0750000005PE6b
Param1=01250000000QHen
Param2=01250000000QHEN
Param3=Motorfleet
Param4=01250000000QHEN
Per the already established above behavior for lookup fields, I would not call this an expected result! Param4 is NOT an upcased looked-up value, it is the record id and that solely because we passed it through a function.
Intriguingly, in my chosen solution, which was to move the computation of the visual force page name into a calculated field in the record, this problem does not appear! I can pass RecordType to a function (in reality a CASE() function, remember that UPPER() in the above examples was only for demo purposes) and it works as expected, i.e., I get the looked-up string, not the Id.
If this is an expected behavior for RecordType, I have yet to encounter where it is documented!