Quirks with case and lookups in field references in visual workflow

I’ve been running into a number of bizarre issues with field references in flows.

To illustrate these, I created a simple flow with a fast lookup to contact to an sobject variable named “sovContact” and a screen to display account fields.

test_flow.png

  1. Cross object field references are case sensitive.

    Works: {!sovContact.Account.Name}

    Does not work (flow will not save) {!sovcontact.account.name}

  2. Regular field references will auto-correct case

    Entering {!sovcontact.firstname} into the display text element will save fine.

    However, when you reopen the screen, it will have magically had case fixed to {!sovContact.FirstName}

  3. Field references to custom lookup fields on the sobject variable are auto-updated incorrectly.

    We have a field on contact that is a lookup to the corresponding salesforce user account, with API name of Salesforce_User_Account__c.

    If you click on “Select resource” and include that field, it will be entered as {!sovContact.Salesforce_User_Account__c}

before_save.png

The flow will save and run properly. Reopen the flow, and take a look at the screen.

after_Save.png

The field has been renamed to {!sovcontact.salesforce_user_account__r}

note that it is all lowercase, and ends in __r now

This is invalid, and the flow will not let you save. You need to change it to {!sovContact.Salesforce_User_Account__r.Id} (making sure that case is correct) in order to save (and stay sane)

Note this is not an issue w/ standard lookup fields as they dont end in __c.

As far as I can tell, none of this is documented in the help documentation on cross object field references in flows and certainly seems buggy to me.

I have an open case looking into this with support - will see how it ends up getting classified.

 
14
Kudos
 
14
Kudos

Now read this

How to throttle an outbound message in Jitterbit

Over the past year, I have been working on a number of integrations using Jitterbit, focused on moving HR data to various systems. We initially went for a transactional approach, where operations would be triggered by outbound messages.... Continue →