h/t to a number of folks on this one, esp Luke Cushanick who shared the idea for this.

Marking fields used in integrations in some way, to prevent them from being deleted, might be useful. Even more useful might be to document which integrations use them, and how.

After some discussion, this can be done using a custom metadata type fairly easily. No code!

Create custom metadata type, lets name it “Integration Field”

Then add 2 fields to the metadata type to track where this is used

Integration name : type = text
Description : type = text area

Now and the magic : create two metadata relationship fields, in order

Object Name : type = metadata relationship, related to entity definition
Field Name : type = metadata relationship, related to field definition

notes:

• the ‘field name’ option will only appear after you create the first relationship field to entity definition
• when...

I have built out a demo scheduled flow that sends an email to each opportunity owner with a list of open opportunities, using a visualforce email template. This flow is much like a report subscription, but with more context, and without nearly as much work of scheduling subscriptions to N users. And - no 5 subscription limit!

The basic approach is covered in this article - which was built on custom objects in our HR system.

In order to avoid hitting the flow iteration limit from building a unique collection of owner Ids (which I can do using this hackish but inefficient approach), I built an invocable apex class that takes a sobject collection and a field, and returns a unique collection of values. This could have some other interesting uses, and opens this flow up to run on up to about 1990 unique active owners, which is pretty robust by my standards…Above that value, you will...

Many options exist to notify folks about salesforce data. I classify them as ‘popcorn’ (email alerts / chatter posts / notifications via workflows/flows/processes) or ‘consolidated’ (report subscriptions, that random opportunity email thing, custom visualforce emails with summarized info).

HR needed to automatically notify managers when people who reported to them had a contract that would expire in 90 days. Report subscriptions dont scale for this. Popcorn is a pain to build, and makes for a fractured user experience, so I wanted to send the manage a single summary email w all the data, on the first of the month.

The full-code way would be a scheduled batch job that sends the email, which can be all code. Nothing crazy, but i would guess a hundred lines or so,

Instead, I used scheduled flows and a visualforce email template in a regular old email alert, which leaves most of the...

this post is just to reference this brilliant url hack by Matt - as eventually this approach will disappear in the comments on the idea to make it unnecessary, as it should be.

the link

Matt’s approach

Try opening the Developer Console to query for the autoproc Profile ID…
SELECT ProfileId FROM User WHERE Alias = ‘autoproc’
…then doctor the URL to get at its setup and enable the relevant Apex Classes:
/_ui/system/user/ProfileApexClassPermissionEdit/e?profile_id={autoproc_profile_id}

I don’t like using default outcome in decision elements. I want to expressly define which path should be taken, and dont want the flow to take a path because i did not anticipate something.

Then I ran into an issue where a flow was finishing early because there was no matching outcome, and i had not mapped the default outcome. This was skipping a final notification step that was critical to the process.

So now, I created a subflow that i can use to send an ‘error’ notification in any flow, and i pass in the flow name, running user name, and ‘error message’. I already have an object I use to log errors from my code, and just write to that object via flow.

This way I can provide a path for the default outcome that expressly triggers an error notification, but can also allow the flow to continue to the next step. Progress!

using the salesforce cli to export a soql query to a csv file is just magic.

sfdx force:data:soql:query -q “select id,parentId,parent.Name,createdDate from feeditem where createdById = ‘0051W0000065wTP’” -r csv > yourfilename.csv

that is it

sfdx
force:data:soql:query
-q “insert query here”
-r csv

boom!

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