Starting November 20, the site will be set to read-only.
On December 4, 2023,
Apex Code Development (90768)
General Development (55146)
Visualforce Development (37251)
Lightning (18265)
APIs and Integration (17146)
Trailhead (11680)
Formulas & Validation Rules Discussion (11337)
Other Salesforce Applications (8116)
Jobs Board (6655)
Force.com Sites & Site.com (4842)
Mobile (2694)
You need to sign in to do that
Don't have an account?
cfaherty I am processing some results from the Metadata API, and I see in the ListView filters some undocumented field names. I am guessing they are similar to the date literals (THIS_WEEK etc), but I can't find a listing of them.
I see CONTACT.CREATED_DATE, and I believe I saw CREATEBY_USER elsewhere. Is there a list of these literals somewhere?
They are not like date literals, but are actually references to underlying code. Based on my experience with the system, I would suggest that these are actually table and column names from the Oracle database that Force.com runs on. For example, a user's full name is listed as CORE.USERS.FULL_NAME, while an Event's End Date is listed as EVENT.END_DATE_TIME. Another example is CASES.CREATED_DATE_DATE_ONLY, which shows a date for when a case was created. These field names appear in reports, list views, and page layouts, among other places.
I've never seen a complete list of these field names, and I don't know of any bona fide way to get at these items. If you edit a page layout, and view its source code, you'll see references to all of these fields all over the place. If they're externally documented, it is certainly one of salesforce.com's best kept secrets. I don't think the metadata API was really meant to be used in a means of external consumption or generation, but only as a way to migrate settings from one organization to another. You should probably stick with the standard web services definition calls if you need to consume this information, such as DescribeLayout, DescribeGlobal, and DescribeSObject[s].
All Answers
They are not like date literals, but are actually references to underlying code. Based on my experience with the system, I would suggest that these are actually table and column names from the Oracle database that Force.com runs on. For example, a user's full name is listed as CORE.USERS.FULL_NAME, while an Event's End Date is listed as EVENT.END_DATE_TIME. Another example is CASES.CREATED_DATE_DATE_ONLY, which shows a date for when a case was created. These field names appear in reports, list views, and page layouts, among other places.
I've never seen a complete list of these field names, and I don't know of any bona fide way to get at these items. If you edit a page layout, and view its source code, you'll see references to all of these fields all over the place. If they're externally documented, it is certainly one of salesforce.com's best kept secrets. I don't think the metadata API was really meant to be used in a means of external consumption or generation, but only as a way to migrate settings from one organization to another. You should probably stick with the standard web services definition calls if you need to consume this information, such as DescribeLayout, DescribeGlobal, and DescribeSObject[s].
It sure makes it harder than it should be to interpret the Metadata. As of now I am only in need of the ListView definitions, and they are only available in the Metadata API. It's really strange that it is filled with these weird field aliases, which in many cases can be exchanged for the documented field names.
In most cases I have been able to use the aliases with SOQL. However I also found that at least one sObject name within ListView is not proper for SOQL. ListView for the Case sObject refers to CASES and SOQL doesn't know what that is so I had to change it to CASE.
Thank you for your comment. I will getting a Metadata dump of an object description and see if it brings up more of these field aliases.