Native dupe management only allows you to reference a single lookup field. So it cannot prevent duplicate junction object records.

By using a (new in spring 20) before save flow to concatenate the two IDs into a single text field, you can prevent duplicate junction object records.

This cannot be done with workflow rules, because of the order of operations. Dupe rules are evaluated at step 6, and workflow at step 11 (as of Feb 2020)

Here are the steps

1. create a text field named Compound Key on your junction object
2. create a flow
3. click on the start button and set the flow to launch on ‘new or updated records’ (you can decide if it fires on insert, update, or both)
4. add an assignment element that sets Compound Key to a formula field which concatenates the two ID fields on the record
5. create and activate a matching rule that matches on Compound Key (exact)
6. create and activate a dupe...

Stripe is a great payment processor. Integration with salesforce requires using a third party tool, of which there are many - though i have not explored them.

I recently discovered the inbound http request connector in Microsoft power automate, fka microsoft flow.

Like most things with flow, its got some quirks. I cannot find this connector for an automated flow, only for an ‘instant’ flow - which is supposed to be triggered manually but in this case fires automatically. So, yeah, onwards.

So create a new flow, type = instant, give it a name, and select ‘when http request received’ as the trigger.

Add a connector, any connector (I chose weather), click save, and you have a REST API endpoint on Azure of your very own. (you have to have another connector to save)

Open up the HTTP connector, and you can see the endpoint (the HTTP POST URL). Copy that.

Now we need to enter...

this is a very short post, that shows one small thing that can be very useful - creating a collection of unique elements in visual workflow

there are now quite a few operators on collections in flow, but none of them are ‘remove duplicates’ or ‘add if new’ or anything like that.

i found a way to do this that requires only a single assignment element - no extra loops or decisions to evaluate if the collection already contains the element required.

This assignment would run within a loop, and would build the collection. The new transform element can build the collection in one step, but it would still need to be deduped.

step 1 : remove all instances of (X)
step 2: add (X)

this ensures that your collection will only contain one copy of the element.

maybe there is an easier way, but this works!

They have arrived with winter20. And they are tricky! Logging my initial thoughts and experiences to something I’ve been really wanting for years.

You can’t directly reference an object, like i want to do a lookup to campaign.

You have to reference an existing lookup field on a child object, like I want to lookup Campaign from Campaign Member, or I want to lookup Accounts on Opportunity.

As far as i can tell the end result is the same - you get the record ID, and you get the record name.

It looks like getting any other fields requires you to do a separate get records step, but thats easy enough.

See the image from the release notes - its looking up account from opportunity.

Here is a screenshot of my lookup to campaign

RecordId allows you to pass in a default value.

For more details, which Brian Kwong’s video here

My use cases
– i use a flow to create contacts, will be...

NPUG Deck

Release notes : https://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/salesforce_release_notes.htm

Useful blogs
jen lee : https://jenwlee.wordpress.com/2019/09/23/winter-20-release-highlights/

gears crm : https://www.gearscrm.com/salesforce-winter-20-features-lightning-sales-cloud-einstein-sales-cloud-and-force/

Significant improvements to two long-neglected areas
Opportunity Contact Roles go business class
– custom fields, page layouts, validation rules
– triggers
– customize which fields display on the related list on opps
– but…
– no workflows / processes (code - not clicks!!)
– no record types :(
– no custom buttons
– And for $(%RI$%($)% sake, I still could not find a way to display the role field itself on the opp related list on contact. you can only see your custom fields on the contact roles related list on opps.

– Editing custom fields are...

I recently built an integration and decided to use the new-in-2017 functionality to customize picklist API values to store the external ID for the system I was integrating into. Per developer force, doing so would “protect your picklist integrations” by allowing “ admins to change what users see when they view and select picklist values on a record, without impacting code that references these values.” And who wants to practice unsafe integration?

Using picklist API values did make things a bit easier on a number of fronts
- no conversion table needed
- ux with picklist is better for users vs using a lookup against an object

And presented one minor challenge
- no easy way to add picklist values + api values in bulk (i pulled it off by creating the filed, exporting the metadata w/ workbench, tweaking the metadata using a text editor, and deploying back via the metadata...

Finally figured out a use case for using quick actions in flows.

They can provide consistency for when you need to do the same thing in multiple flows / processes, and want to ensure that specific fields are populated.

All required fields on the action layout are required when you use the action in a flow / process. Any optional fields on the action layout are available to be added if needed. But - any fields not on the layout are not available, so it is also a constraint.

Some use cases I can envision

• creating a case on flow failure
• creating contacts / leads
• logging calls

My use case was a custom object called ‘integration request’ that I have setup to centralize a few callouts to external systems. Its like I imagine platform events could be used - if I understood platform events.

So there is a global action like so:

And in the flow, I can leverage the action like so:

And...

A sporadically maintained list of coal seams smoldering deep in the caverns of salesforce.com that cause needless liver damage in many an awesome admin.

In honor of summer19, this post now has the subtitle of:

101 things that might be more helpful than confetti (which, for the record, is actually kinda fun).

Misc Nonsense w Fields and Reports and such

1. parent case field not available on case close layout
2. parent campaign field not available on activity with campaign report type
3. primary contact not available on activity with campaign report type.
4. primary campaign source not available on opp related lists - without formula field
5. Amount and expected revenue not available on standard campaigns w opportunities report type, but available w formula fields
6. cant load data to description field on campaign member?
7. link to view hierarchy on case list view (why do i have to create a field for...

There are many good form tools that integrate with Salesforce. Salesforce even has their own surveys product now - which will be interesting to watch.

But i’m going to illustrate how to roll your own using visual workflow, embedded in a visualforce page, on a force.com (er, lightning platform) site.

If you just want to see the finished product, go here and try it out

2022 UPDATE

h/t from Peter Churchill - you can easily embed flows in public experience cloud sites.

try it out - its the exact same flow in experience cloud

and running flow in system mode now allows updating existing objects - contacts in my case.

and the ux for flows in visualforce pages seems ok now, though there is no real reason to use that.

here are the docs re embedding flow in experience builder community cloud lightning jedi temple site

~~And some caveats : Site external users cant update any...

The ability to use quick actions in process builder / flow has been around for a few years, but i’ve never seen a reason to use them.

I figured some out this weekend. Here are the use cases I see.

a) standardization :
if you will do the same thing (or almost the same thing) multiple times, building an action ensure standardization, and allows for easy updates if a change is needed. you can enforce required fields at the action level, even if the fields are not required at the object level. its a template / contract for creating an object. powerful stuff.

Note that this can be useful for doing the same thing on multiple nodes in a single process, or if processes on different records do the same action, say create a task or a case.

b) in process builder, quick actions can let you update unrelated records (as long as you know the record ID). so you dont need a lookup field to the...