I came, I saw U2, I’m flying home.

My dreamforce is over, though today is a huge day with all of the product keynotes. Here are my initial takeaways this year, from the perspective of a declarative developer at 30,000 feet.

Lightning is maturing. Its no longer the lanky teenager than just shot up 18 inches. Feature parity on the key missing pieces (obscure stuff like campaign members) is coming in the next 2 releases, while Salesforce is delivering new complex functionality faster than ever. The power of the lightning platform is starting to shine. I will need to work to become fluent with the declarative side of lightning and to get sufficient understanding of how lightning components and the code side of lightning work.

AI is here, now The use cases (and the pricing) will evolve - but there are real applications now. Some that resonate with me are automatic logging of emails...

Scenario:
Check if record (meeting certain criteria) already exists, if not redirect to standard create new page, else redirect to view record

Example:
client services - wants all records for a client from a single day under a single case. so if case already exists for a contact for today, display message and redirect to record on finish, else allow user to create new case

This can be done w/ visualforce. Testing to see how it works w visual workflow.

Trying a few approaches:
A) flow + use retURL to redirect to new case page based

strategy:
Use retURL on button that launches flow to redirect to new case page
If case exists, use screen to display link to case (and no finish button so no redirect possible)
If no case exists, go straight to redirect (no screen).

steps:
pass contactID to flow variable in button
use fast lookup to check if case exists
Use decision to evaluate whether...

TL/DR: you should turn on API Access Control as soon as you can!

ORIGINAL POST:

There are tons of amazing applications out there that connect to Salesforce - heroku apps like the perm comparator, salesforce plugins for excel, chrome extensions, and on and on. These tools allow users and admins to do amazing things, and they all do them using APIs that Salesforce provides.

However, there has been, until recently, very limited abilities to control which apps a given user can access. By default, any user with the API enabled permission can use any extension or third party tool out there without any additional permissions. Period. And this permission is enabled by default for all standard profiles in a developer org, and likely is enabled for most of the profiles in your org as it is needed to access Salesforce1 and other key apps.

Its important to emphasize that these...

This post is a bit embarrassing to write, as I have to admit that I have been totally misunderstanding 18 character Ids for just about as long as I have known about them.

The title spells it out: 18 character IDs are case sensitive, period. Even though the definition of CaseSafeID on the help and training site states:

This formula replaces the 15-character Id with the 18-character, case-insensitive ID.

and even though there are help and training articles that call the 18 character Id ‘not case sensitive’ and blog posts that say

The 18-character ID is not case-sensitive. In other words, 001C000000O4OOIIA2 and 001c000000o4ooiia2 both refer to the same record.

– this simply is not the case (ha).

The 18 character Id is unique, and as such can be compared by tools, like excel’s vlookup function, that are not case sensitive.

But if you change the case on an 18 character Id, it is no...

The Spring 16 release contains a ‘fix’ for a problem that IMHO does not exist.

update: the link to help and training above now pulls up a blank article. google’s cache shows the article describing the ‘fix’. Perhaps a change is in the air.

Prior to spring16, read access to a contact was sufficient for a user to add the contact to a campaign. So you could have a public read-only or private contact sharing model, while allowing users to add any contacts they could see to campaigns.

Apparently that was a problem. So, the ‘fix’ was to automatically hide the add to campaign button unless the user has edit on the record. However, as this is not enforced on list views or reports, if that is a serious security issue, then its not really fixed. Regardless, this quickly started to cause me problems. It started with increasing support requests from users, and soon I was resorting to adding...

There is a great app called FieldTrip that will let you know which fields are actually populated in records, but deep diving into eclipse, or using brute force, have been the only way that I am aware of to see which ones are actually visible on which page layout.

Until now. By using workbench.developerforce.com to retrieve the page layout metadata, along with OpenRefine to parse the XML to a spreadsheet, it becomes ridiculously easy to pull out this information.

Update: the most awesome and powerful Amber Boaz pointed me at an app called ‘cloud config’ that lets you export all your metadata info to excel, including layouts. Its awesome and definitely has a place in the admins toolkit. Using refine as described in this post makes it ridiculously easy to compare field visibility across layouts, and do other fun things, so these are definitely complementary options.

So, to pull this...

** RATHER UNFORTUNATE UPDATE - NOV 2018**
Did some sleuthing and discovered that geocodes bug out sometimes when there is something like a room number that data.com doesnt like in the street address (even though the address is valid, the google map component in sfdc shows the address properly, and there is a valid city state and zip that could be used).

Ran the gauntlet and got a known issue logged for it…odds of it ever being fixed == low. (UPDATE: NEVER)

So This mostly makes geocodes somewhat less useful. You will need to run a report to see records that have an address but no geocode, to see which ones are being skipped, and then manually tweak them until the data.com gremlins are satisfied with your efforts.

UPDATE JAN 2018
many of the old links dont work, and there is not a lot of documentation i could find. here are a couple of links from the release notes to get...

Including case comments in the case assignment email allows the recipient to see exactly what is going on before even logging in to Salesforce.

You need a visualforce email template for this. You can use an apex:repeat component in your email template, but there is no sort order on those. Really, as best as I can find, its just random.

So I went ahead and created a custom component to select comments and sort. Now i can include just the last 3 comments to keep it simple, and its sorted by date, with most recent first.

Credit: This StackExchange post was hugely helpful in making this happen

I altered the solution a bit to use an apex:repeat in a table in the custom component, instead of a datalist, as i found the formatting better. The code for controller, component, test class, and vf email template is all copied below for your pleasure.

controller

public class

While permission sets makes assigning permissions a breeze, it can be a bit of a bear to audit all 150 of them. By audit, i mean see which ones give you [some permission] on [some object]

So this blog post will cover a number of ways to audit permission sets, and specifically will go into details on how to audit record type access using the metadata api, as that is the only way that I could find. Note that this would work for profiles or permission sets.

Now the first place to go is to use the list view itself. You can display and edit CRED permissions for any object on a permission set list view, just like you can with profiles. And that means you can edit them all at once (up to 200 at a time).

So, if you want to see which permission sets give Delete access on accounts, that is the first place to go. Just note that the search functionality for setting the ‘filter criteria’ is...

When a user is deactivated, we want to notify their manager to review the records that the User owns, to determine which ones should be transferred and which ones can be left alone.

With Spring 15, most any user can edit a record owned by an inactive user so it makes sense to review and leave them alone unless someone is taking over the relationship / opportunity.

So, we pulled together a workflow rule that triggers an email to manager
that shows a count of records owned by user, and links to reports where they can view records.

The email uses a visualforce email template, with a custom component that calculates the number of records owned by the user, and includes a link to reports that are filtered by the UserID, so it shows the actual records owned by the user.

Note: reports must filter on 18 character ID - as that is what the component delivers, since its running in code.

I’m...