Check out Jessie’s exploration of the limits frontier as she puts the new Map Collection action through its paces.
Chris Van Der Merwe has written a nice post on how he customized the datatableFSC component to handle a single custom object. His post gives easy to follow step-by-step instructions that a non-developer can easily follow to create a version of the datatable componet to support any object of their choice.
This action can be used to generate a list of record types for a specific object. This can be useful when you would like to present a record type selector to the user. Can be used as inputs to the QuickChoice managed package by setting Input Mode to “Dual String Collections”. Pass in one output collection for Labels and one for the underlying values
|Object Name||String||API name of the target object example “Task” or “MyObject__c”|
|ignoreMasterRecordType||Boolean||If “on” then “Master” will not be added to the list of record types|
|onlyReturnActiveRecordTypes||Boolean||If “on” then only active record types will be added to the list|
|onlyReturnRecordTypesAvailableToCurrentUser||Boolean||If “on” then only record types available to the current user will be returned|
|errors||String||captures details of any error that occurred|
|recordTypeIds||String||Ids of the records types.|
|recordTypeNames||String||Names of the record types.|
The Email Alerts that are available in Workflow Rules are limited in functionality. I remember thinking this as a customer of Salesforce more than 15 years ago. Salesforce isn’t investing in Email Alerts because it wants to transition to more modern technology. In the meantime, here’s an approach for getting massively customizable email into your Workflow Rules.
In this example, we’ll assume that you have a Workflow Rule that runs on Contact every time the email address of the contact changes. You want to send certain things to certain recipients, but Email Alerts don’t give you enough flexibility.
With Process Builder and Flow you can get the flexibility you need, but you’ll need to trigger the process by updating a special field.
- Add a text field to your object. Suppose you are sending emails about something affecting Contact. In this case, add a boolean field called “TriggerEmailSend” and set it by default to False. Modify your Workflow Rule to set this field to true using an Update Field
- Create a Flow that uses the Send Rich Email action. Use the “Autolaunched” Flow Type. Configure the flow with input variables to capture any information you’re going to need in your email. For example, if you want your email to have a link that brings the user to a record, you’ll need a recordId input variable. Activate this flow.
- Create a Process Builder trigger that runs whenever the TriggerEmailSend field is changed to True on the Contact object. Have it call the Flow you’ve created, passing it the recordId of the Contact that triggered the change.
- The Flow that you created in step 2 above should also modify the contact using an Update Record element with an Assignment element to set the TriggerEmailSend back to False.
This process will get easier later this year, when Flow gets the ability to trigger on all record changes. That will eliminate the Process Builder step.
Note that you may not need step 1 at all. You can create a Process Builder process that triggers on the same field that triggered your workflow rule.
UPDATE: Syntax has changed in the Beta version available in Summer ’20. To see the changes, click here.
An early version of the documentation and tools for crafting Custom Property Editors for invocable actions is now available here.
The materials include a 35 minute walkthrough that shows how to take the current Send Rich Email Property Editor:
and turn it into this:
Learn more from the Beta Documentation
I have added a new parameter to the quickChoiceFSC component. You can now choose to display visual card pickers in a single column or side by side in dual columns.
One of the coolest things I’m seeing as UnofficialSF grows is admin turning into beginner developers and beginner developers turning into better and better developers.
A key milestone on this pathway is creating your first pull request. A Pull Request is a very badly named thing that should be called a Code Submission. It represents someone saying “I’ve improved at least one code file of an existing project, and here are the improvements. If the maintainer of the project is comfortable with the changes, they should merge them in”.
For the Flowhana to achieve its full potential, we need more members to break through and get comfortable creating pull requests.
Here’s the basic trail….
- First of all, don’t worry that you’ll mess things up. Pull Requests sit atop a framework that has been developing over the last 20 years called git, and it ensures that no matter what happens, any change you make to the code can always be undone. There are tons of checks and balances. You can always throw stuff away and start over without losing any of your actual code.
- Secondly, don’t worry that your code isn’t good enough. Every developer starts out as a beginner. This will be a very friendly environment and you’ll learn a ton.
Learning the Basics
- Go to the repo (repository of code) up on Github that most interests you and look around. Get a feel for the features and how it’s structured. Get a github account if you don’t already have one.
2) Go through this tutorial, which provides a quick, simple introduction to the three core concepts: repos, branches, and pull requests.
3) Make an initial decision about what tools you’re going to use on your computer to manage your local copies of various code repositories. The big choice is whether you want to go with the command line or use a visual tool, and, if you want to use a visual tool, whether you want to us the VSCode tool that Salesforce recommends for development or a more git-centric tool like Github for Desktop. My recommendation is to use the command line if you’re already comfortable with managing things via the command line, but otherwise try Github for Desktop. VSCode is great for development but not quite as easy to get started with for git usage.
4) Next, explore the idea of remote and local repos. Github maintains the current “master” version of several repos that are associated with unofficialsf. When you want to work with one of them, you work with it on your local computer (from where you’ll do a bunch of deploys to Salesforce orgs). The process of creating a copy on your own computer so you can work with it is called cloning.
5) Next, study up on Branches. Branches are the heart of the collaborative model. Each branch is essentially a pointer to particular series of code changes. When you create a new branch ‘off’ of an existing code line, a junction is created and there are subsequently two different code lines. The rest of the community continues down the original branch while you get to make changes on your own code line. Ultimately, a Pull Request represents a request to merge your changes back into that existing code line that you originally branched off of. The number one thing that will make your initial experiences with code collaboration work better is to get a good understanding of branches and always know what branch you currently are on. To get a really good grounding of Branches, I recommend reading through the git book up through chapter 3.5. Even if you’re not using the command line, the diagrams alone are worth checking this out. It’s really useful to grok the idea that even though we metaphorically talk about codelines and tree-like branches, a ‘Branch’ is really just a pointer to a specific commit.
At this point, you’re ready to start contributing code to flow projects.
A quick note on forking. Forking a repo into your github account allows you to make changes without getting any access to the original repo. However, if you are interested in making contributions, don’t hesitate to ask for contributor rights on projects. When you’re a contributor, you still create branches and pull requests, but it’s a little simpler because you’re working with the main repo and not a forked copy. I welcome contributors to all of my repos.
So now we can discuss the core workflow you’ll use:
- identify a needed change in an existing project/repo
- if you don’t already have a local copy of the repo from a previous clone or fork, do a clone or fork.
- deploy your local copy to a dev org where you can work with it (see “Deployment, Orgs and SFDX” below)
- Create a working branch, make changes to the code and flows, and deploy the changes to your dev org. Frequently commit and check your code changes into your local repo, and periodically push your local repo to your github repo so you’ve got a safe copy up there. Iterate until you’re done.
- if your work includes apex code, add one or more test methods to test your work
- when you’re done, make sure all of your changes are pushed up to the github master repository on your working branch.
- create a pull request, indicating that you’re suggesting that any changes between your working branch and the current master branch be resolved by merging in your changes.
- wait for a review. someone like me will look at the code and possibly give you feedback.
- Ultimately, when the code is ready, someone with merge rights will merge your changes into the master branch of the master repository.
Deployment, Orgs and SFDX
We highly recommend using SFDX as part of your development process. It’s important to keep SFDX and all of the above stuff distinct, though. The above stuff is about code management and git, and sfdx is about salesforce org and metadata management. They work together really well, but you have to take it one step at a time.
If you’re like me, when you get to step 4 and deployment, you’ll use sfdx to create temporary dev orgs called scratch orgs where you can deploy and test in isolation. YOu’ll take advantage of super useful tracking built into sfdx that allows you push code up from your local machine and also make declarative changes (like building a flow on the org in Flow Builder) and then pull the metadata down into your local machine’s repo, so that all the changes are always together.
It’s also possible to do deployments the old way with packages and workbench.
To learn more about sfdx, start here.
There’s a lot here. Don’t rush it. I would recommend looking at this as a sort-of 1 year course of learning. When you get frustrated, take a break. search stack exchange when you run into problems. Enjoy the journey.
Updated 1/20. Cleanup. converted to LWC.
This is an extremely simple port of the standard inputRichText control to work as a Flow Screen Component.
This component exposes a single attribute called “value”. It can be used both as an input parameter to set the starting values and as an output parameter to pass out the selected time.
You can display the rich text output of these components in Flows, using either the standard Display Text Field or the new formattedRichText Flow Screen Component
Note, though, that the standard Flow Display Text field is capable of displaying some of the rich text effects, but not all:
Variable Handling Notes
When added to a screen, this screen component currently has Manually Specify Variables (Advanced) turned on. to get the value out of it, you’ll want to map the value to a variable of type Text. However, you can also turn off manual specification of variables and use automation output handling. Some of the tradeoffs are discussed here.