MetadataService is a subset of Andy Fawcett’s legendary Apex-Mdapi metadata service project, slimmed down and packaged to be useful to Flow Developers as a dependency.
If you’re using these metadata deployment and retrieval services in your own Flow Action or Screen Component, consider simply requiring that this package be installed as a prerequisite
Learn more here.
V1.0 Unmanaged 7/5/20
There are some powerful data structures that are currently available only through retrieval and deployment via the metadata API. For example, the Process Builder Converter tool works by first retrieving a process builder process as a piece of flow metadata, then editing the metadata so it can be opened in Flow Builder, and then deploying the modified flow metadata as a new, separate flow.
In general, using metadata deployment and retrieval is the last resort you should use. If your data is accessible via the UI API, the Tooling API, or via a REST interface, those are likely to be preferable. One reason is that metadata deployment may trigger a recompilation of all of the apex classes on your org, and that will pause your deployment until it’s finished. So while metadata deployment will generally go very quickly on developer edition orgs, it might be much slower on a production org. (As a note, you can control whether your metadata deployments trigger a recompilation with this checkbox:
Despite these issues, sometimes Metadata deployment is a great tool to use. The Process Builder example is a good one.
Another example involves creating, editing, and deleting ListViews via a Flow Action. While ListViews can be read via UI API and REST, they can only be created, edited, or deleted by doing metadata deployment of ListView metadata.
There are two sets of tools you can use to build Flow Actions and Screen Components that use Metadata Deployment and Retrieval.
The first tool is the legendary Apex Metadata Service created by Andy Fawcett. This abstracts a lot of gnarly SOAP transactions into nice clean API’s. Here’s an example of a Flow Action making use of the Metadata Service to create ListViews:
The reason this works is that MetadataService has gone and created a wrapper class for each piece of Salesforce metadata. In the code above, you can see that we’re able to reference MetadataService.ListView(). Once we have one of the ListView objects, we can simply fill it with updated values, and then call createMetadata on it. There are similar methods for updating, deleting and reading.
You can peruse the vast set of available objects by scrolling through the main class file here.
When we went to create the process builder converter, though, we weren’t able to use the above method. The reason is that the current MetadataService only has updated metadata through API version 42, from 2017. We needed to create flow metadata that used brand new additions that had only been added in version 48.0
You can see here, that the Flow definition in Metadata Service (era 2017)…
lacks the brand new metadata element that stores new Flow triggering information:
Hopefully, someone will update the MetadataService to the latest API. In the meantime, you can solve this problem because the MetadataService also provides direct access to lower level deploy and retrieve methods that don’t require you to populate one of the metadata objects.
When you operate at this lower level, you have to directly parse and modify the metadata xml. Then you have to zip it up with base 64 encoding, and then you call MetadataService’s ‘deploy’ method directly. This has been implemented asynchronously, so we carry it out via a Flow screen component called TransferMetadata that can sit there on a flow screen and poll until a response is received.
While this may sound a little intimidating, you can just take and copy the code we used.
To streamline the efforts of developers who want to build tools like Create or Edit ListViews, we’ve packaged the necessary MetadataService files into a useful package that you can just require as a dependency. This package leaves out some extraneous files from the repo but has everything necessary to carry out deployment and retrieval.
In general we’re starting to move towards base libraries to avoid collisions and simplify packaging for new actions and developments.
Install it here.
Use UpsertRecords when you want to take a collection that may or may not already exist in the database and save it. If the records in the collection have valid Id values, the corresponding records in the database will be updated with the flow’s collection. If not, new records will be created and saved.
UpsertRecords provides functionality similar to the Apex ‘upsert‘ command. You can optionally provide the name of a field on your object that is the externalId (currently disabled until Summer ’20), and you can specify that you want partial saving to work even if some of the saves fail (‘all or none’).
This functionality is available in the CollectionActions package starting with version 1.19.2
You can provide either a collection or an individual record (and in fact can provide both), but because of a limitation in the action configuration framework, you have to specify both types, even if you’re only using one, like this:
| Attribute | Type |
| inputCollection | List<SObject> |
| inputRecord | SObject |
| externalIdFieldName | String (note: this is temporarily disabled but will be added in Summer ’20) |
| allOrNone | Boolean |
This action currently has an output called ‘placeholder’ that should just be ignored. If an error occurs during the upsert, the error message will be thrown back to the flow
Install the Collection Actions package, starting with 1.19.2
June was a big month for Flow demo videos. First we had Summer ’20 Release Readiness Live, with special cameos by my mother-in-law’s dog, a baby, and a dubious plant.
A week later, at TrailheaDX, another Flow presentation was given. This one included a sneak preview of two upcoming blockbuster features: Multicolumn Screens and Autolayout Canvas.
Check it out!
This solid post has a nice comparison of standard picklist behavior and QuickChoice behavior.
Setup and Installation steps (View Part 1 for demo video and details on the building blocks)
STEP 1: Install package
OR
STEP 2: Setup the environment
STEP 3: Create Users of the app.
STEP 4: Assign permissions
STEP 5: Add Data to custom objects
| Name | Description | Action Reference | Acceptance Label | Rejection Label | ||
| 1 | Priority Message: Tax Day | Tax day is in 6 weeks! Get more detail. | Tax_Flow | Accept | Reject | |
| 2 | Priority Message: Well Being Survey | Our records indicate that you have not taken the Well Being Survey. Please take a few minutes to complete it. | Well_Being_Survey_Flow | Accept | Reject | |
| 3 | Work.com Contact Risk Alert | Alert! You have recently come in contact with someone who has tested positive for COVID -19. Please contact the health center for more details. | Contact_Risk | Accept | Reject | |
| 4 | Return to Work Shift Days | Shift_Flow | Accept | Reject | ||
| 5 | Training Recommendation | Your manager has identified that you will benefit from the Great Salesforce Leaders training. Click to enroll. | Enrollment_Flow | Accept | Reject |
STEP 6: Set up the flow component to accept input for which messages and their respective priorities to be surfaced on the NBS Component
