Yes Pat,  by default we generally use the 18 char ID when we do comparisons or conditions.  That is what you should be in the habit of using. 

Sometimes a process will require the 15 char ID,  and so we include the “Id15” field for the base object of a Model - which you can pass in merges or access in Javascript. 

But things usually run off the 18… 

Well, most times when I want to hard code it, I just go the record and copy the Id out of the URL. Where else is it easily attainable?

Hey Pat -

Ideally, you could avoid the entire 15/18 problem all together.  In general, I’d recommend against hardcoding anything, especially ID values from SFDC.  There are many reasons for this, the primary of which is that as you move from org to org (sandbox, prod, etc.), IDs change and hence you’ll have to go through all of your pages and make sure you update the IDs that you used.

It appears that you are evaluating RecordType in the above.  Here’s a couple of alternatives:

1) Evaluate against RecordType.Name instead of RecordTypeId.  This lets you use a “Friendly name” that will be consistent in each org you are deployed in.

2) Apply SFDC formulas that give true/false answers to the questions that you care about (e.g. IsXYZRecordType) - this is what we’re doing.  This allows you to control the conditional evaluation in SFDC and avoid hardcoding even the name (or the id in your example) in Skuid. Plus, if the name ever changes, you don’t have to change your skuid page(s), just the SFDC formula.

If you’re set on using the actual ID, there are a few ways to find the 18 version including SOQL, export using Data loader, etc.  Ids are all based on a standard format so with this in mind, I did a quick search and I found this: http://www.adminbooster.com/tool/15to18.  Search engines and the internet are our friends

Getting the 18-digit RecordTypeId is unnecessarily difficult from the Setup menu. From Skuid you can get it pretty quick either from JavaScript or from Apex like this:

From JavaScript:

console.log(skuid.model.getModel(‘MyModel’).recordTypeInfos); // Returns metadata for all RecordTypes available

From Anonymous Apex:

skuid.Utils.GetRecordTypeIdsByDeveloperName(YOUR_OBJECT__C.SObjectType.getDescribe()).get(RECORD_TYPE_API_NAME);

er … uh … what is anonymous apex?

I think that I’m over-thinking this. The record type name is very unlikely to ever change. I will render based on the name and be done with it. If the name needs to be changed, a formula may or may not reflect the newly desired output. I’d have to make additional formulas.

Hey Pat -

Regarding anonymous apex, once again, the internet and a search engine are your friend - https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=anonymous%2….

As for the formula, understand what you are saying but rather than take the approach that the formula is named the same same thing as the recordtype name itself, you would want to name the formula in terms of a business rule question/answer.  For example, in our case, we need to show/hide information on the screen based type of record.  However, the formula is “ShowAccountingSection” which doesn’t match the name of the recordtype.  By separating the physical name of the recordtype from the rule you are evaluating, you avoid having to create a new formula in the future when the name changes, but the business rule doesn’t.

That said, just evaluating the name in skuid works and is portable from org to org.

Oh! I like it now. A formula I’d make would be “ShowLocations”. If it’s working as expected, then review the formula. Done.

I just create a text formula field on each Salesforce object using the formula:

CASESAFEID(Id) where Id is the Salesforce Id standard field of the object.

It will then provide the 18 digit id just like any other field.