These are looking like the best thing since flows themselves…so many use cases i can think of, primarily for onboarding new users, but also for announcements, tips / tricks, and complex authentication protocols.

User login flows came out in Spring 15, and they let you present the user with a flow, between them entering their password, and getting full access to Salesforce. And, you can send the user down different paths based on really anything - profile, role, last login date, some value in a custom setting, the time of day, the value of salesforce stock, whatever you can think of, is really powerful.

So after this screen, you can do, or have the user do…whatever you want.

For example…

Clicking next / finish takes the user to Salesforce - and you can customize the flow finish location if you desire!

In this article, I will present an overview of a login flow, which present...

I recently had a global action that I wanted to display on the home page, but not on object detail pages. It looked like I would have to add this action to the global publisher layout, and then override the publisher layouts on all objects in order to remove it from objects. This would have been a ton of work and was clearly not worth it. However, in digging into it, we found that there is a way to configure that separately, that is not to my knowledge documented.

First a bit of an overview on chatter publishers and where they are configured.

There are 4 chatter publishers that can be configured.

• Home page
• Record detail pages
• Chatter profile
• Chatter groups

By default, all of these publishers display the Actions that are set in the Global Publisher Layout assigned to the users profile.

To customize this layout, go to setup - create - global actions - publisher layouts

And...

UPDATE - 7.7.15: This will eventually trigger an error and is now a known issue, with expected behavior listed as “TBD”. So as I expected, its not known whether this will be a supported use case or not. Using a fast lookup / update this will run about 30 times before failing, using a regular lookup / update will run about 90 times before failing. Use at your own risk, but its still pretty damn cool.

In a previous post I provided a proof-of-concept for a simple flow that posts to chatter every hour, forever, on an opportunity. Will call that version A.

I have iterated to demonstrate a version with controls (Version B), so it fires on a recurring basis as long as the opportunity is open. From there, I have created a version (Version C) that waits for last modified date, thereby only posting if the record has been modified within the given time period.

Version B of the flow consists...

UPDATE - 7-7-15: This will eventually trigger an error, and is a known issue w expected behavior ‘TBD’. See updated post - Infinite Flow Refined. for more details on the error and the infinite flow model

It is possible to set up a recurring event (say a birthday reminder that fires every year) using 2 workflow rules. Its not all that pretty, but it works.

There are open ideas for recurring time based rules, including one that was marked as delivered in spring 15 via process builder.

I set about trying to build such functionality using process builder, and had a hard time getting it to work as there are a lot of options to poke around with, its hard to debug processes, and so on.

Since process builder on the back end spits out a flow, I thought I might have better luck there, and indeed I did. So I shall demonstrate how to build a flow that continues, forever.

Sample use case...

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.

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

captains log : star date april 2018 – check out this new post that allows using the lightning runtime on a flow in a visualforce page in a site. New and improved y'all. Original post is below:

The native Salesforce stay-in-touch functionality is great, unless you want to change anything at all with how it works, as there is currently nothing at all that can be modified (though there is an idea with 16,000 points that you can vote for.)

In this post I will demonstrate how, by using visual workflow embedded on a public force.com site, its possible to pass in the ID of an existing contact via a URL parameter, display the values for a non-authenticated user to edit, and to save the edits back to Salesforce.

There is one major constraint to work around. Salesforce does not permit the Site Guest User to edit contacts, so you have to use a custom “holding” object along with an...

This post is part of a series on building a replacement for stay-in-touch using visual workflow

The visualforce page is very simple, no controller required. It is designed to pull the contact ID from the query string (the URL).

This help article shows how to embed a flow in a visualforce page, and it looks like

<apex:page>
  <flow:interview name="MyUniqueFlowName"/>
</apex:page>

This help article shows how to set flow variables from a visualforce page, which then looks like

<apex:page>
    <flow:interview name="flowname">
        <apex:param name="myVariable" value="01010101"/>
    </flow:interview>
</apex:page>

Finally, this article shows how to pull parameters from the query string into a visualforce page, which looks like

$CurrentPage.parameters.parameter_name

So, putting it all together, your visualforce page would look like

<apex:page >
    <flow:interview

Not possible you say? Well, yes, technically you are correct. However, I needed to use the standard mass email functionality in Salesforce, and to include both contact merge fields (First Name, Email) and campaign merge fields (Campaign name, Start date) in a URL in an email that would be sent every month from a new campaign.

The best solution I could come up with requires a bit of cut and paste, and a clever hack, but should be foolproof in that it doesnt require manually reassembling the URL in the email - just pasting a new link for each send.

My approach was as follows:

1. create a formula field on the campaign object to pull the campaign merge fields into the URL
2. On said formula field, after the campaign merge fields, include the contact merge fields that would get populated when the email was sent.

So the formula field, simplified to only include one Campaign field and one...

This will be a quick and dirty overview of using Fast lookups, loops, assignments, and Fast Create elements to iterate through a collection of records and create N number of child records.

Its awesome. Caveat - I brute forced my way through this due to a recent need and cannot say whether or not any of this is “correct”, but it works. There are likely governor limits and what-not that may pop up in production scenarios, and I will try to hit on those where I can.

So the sample use case I will model is as follows - take all of the contacts in an account and add them to a campaign. This requires the following steps

1. Fast lookup - lookup all contacts in the account and assign them to an Sobject collection of contacts

2. Loop through the Sobject collection of contacts, and for each record, do the following
   -create a Campaign Member Sobject variable record using the contact ID, and a fixed...

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. That turned out to not work well with the Netsuite API, without purchasing a rather expensive user license that would allow concurrent API sessions. However, at the time we needed to “throttle” SFDC outbound messages, which can contain up to 200 records at a time, so that they processed one record at a time. I’m recording how we did this here, as I’m sure I will need to reference it later.

Its quite easy to do, once you have created an web service operation to consume the outbound message (will post on that later).

The outbound message operation in Jitterbit has 3 components

1. Web service method
2. Transformation
3. Response

In order to throttle the...