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

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