my posts
http://goravseth.com/infinite-flow-refined
http://goravseth.com/user-login-interface-flows
http://goravseth.com/dyanmic-approvals-in-salesforce-just-got-a-lot-easier
http://goravseth.com/working-with-attachments-in-visual-workflow
http://goravseth.com/debugging-flows
http://goravseth.com/replacement-for-stay-in-touch-using-flows
http://goravseth.com/flow-to-check-and-redirect-to-create-edit-if
http://goravseth.com/creating-child-records-using-visual-workflow
http://goravseth.com/triggering-an-email-the-first-time-a-user-does-x
http://goravseth.com/lookup-in-flow-can-use-15-or-18-character-id
http://goravseth.com/a-flow-to-clone-a-hierarchy-of-any-depth

other folks posts and blogs
5 best practices in building a flow
a naming convention for flow elements
its very important to use a naming convention on your flows as well, ie Object - Functionality
customize what happens when a...

There are plenty of obscure-but-worth ideas, but those wont show up in this post. This post is an ongoing list of ideas that shouldnt be ideas at all.

Like..

Adding help text for name fields

Description fields on public groups

will keep adding them as i come across them

Buried deep on p 359 in the winter 17 release notes, lies this understated gem of a feature

Assign a Custom Record Page to Lightning Apps, or Make It the Default for All

3 sentences of description and zero screenshots later, and its over.

And, you may ask, why is this such a killer feature?

It embraces the fact that one person can have multiple roles - and that in those different roles, they need to do, and see, different things. This is about the end user being able to see and do what they need to do the task at hand, which is very common at nonprofits, and I imagine far beyond.

Until now, one user has a profile, and when they looked at an account, it would always have the page layout reflected by their profile. Sure, you could have different account record types, but the sales user would always see one layout for one account type. There was no easy way for them to see a...

You can manipulate attachments in visual workflow (i’m working with the old-fashioned attachments object, but this should work w/ files, which are stored as contentDocument / contentVersion / contentDocumentLink).

What works: manipulating existing attachments by looking up the attachment(s) and storing them in a sObject variable/collection, including the body field. Use assignment elements to set the ParentID to its new parent, and use a fast create to insert the sObject variable/collection.

What wont work: Doing anything with the body field, other than including it in a sObject variable/collection. For example, I tried to map a text variable to body and create a new text attachment, and that fails. Body is a base64 field type, and I have not found any flow field type that can map to it. So you can only lookup an existing attachment and change the parent ID - you cant create new...

With a small trick, Dynamic choice elements in visual workflow can be used to display multiple records, and only act on the selected record(s).

In a previous post, I described how to create a button that could copy all attachments from an email to the parent case.

I’ll now describe a more advanced version, which uses a dynamic choice to display a checkbox for each attachment, and only attaches the selected item(s).

The dynamic choice flow resource makes it straightforward to display multiple records as checkboxes. However, it does not provide a clear mechanism to take action when multiple records are selected. Dynamic Choices can only be mapped to a sObject variable, not a sObject collection. sObject variables can only store a single record, and therefore per the docs, only the most recently selected record that will be stored.

When a multi-select choice field uses a dynamic...

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...