in assignment elements, flow date fields do not accept globalconstant.empty string, or any values other than a proper date.

i needed to set one to null.

i was able to create a flow formula field, type = date, and value = NULL

and it worked!

full disclosure - maybe you can just leave it blank in the assignment element. didnt test that! tbd.

using flow and external services to cause minor mayhem

the use case : merge salesforce data into a word doc using flow

approach : use a flow button to callout to a microsoft power automate endpoint via external services

useful posts
https://katiekodes.com/flow-apex-defined-data-types/
https://help.salesforce.com/articleView?id=enhanced_external_services_example_schema.htm&type=5

the learnings :
a) no apex defined data types need to be created- the external service schema definition itself is the apex defined data type. just create a variable, type = apex-defined, and for the apex class, select ExternalService__YourExtServiceMethod - it will be waiting for you

UPDATE - DEC 2020 : Spring21 should offer this natively, per poking in my pre-release org. Will link to release notes when they are available.

Before save flows do not directly offer functions like ISCHANGED, ISNEW, and PRIORVALUE

ISNEW can be handled by checking if $record.id is null (h/t to Jen Lee)

To handle ISCHANGED or PRIORVALUE, use a get records element to get the current record, which gives you the values from before your auto-launched-before-save-flow updates it.

To do this, select your object, and filter for id = $record.id
make sure to only store the first record, you dont need a collection here!

Now you can check if it was changed in a decision element by comparing the new value ($record.yourField) with the prior value (getRecord.yourField)

in my case i wanted to check if it was equal to a certain value, and changed, so i went with a decision like this

to just...

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 loops or decisions required

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