CLI-Based Flow Execution

[VivekMChawla]

I'm Vivek M. Chawla, the new Product Manager for the Salesforce CLI.

I'd like your feedback on a feature we're considering: Execute an autolaunched flow from the CLI.

What's the idea?

• Provide a single command that allows execution of an autolaunched flow from the Salesforce CLI
• Allow both synchronous (i.e. --wait) and asynchronous execution from the CLI

Why build this?

• While it is possible to execute autolaunched flows from the REST API, doing so requires special expertise
  • A working understanding of the Salesforce REST API
  • The acquisition of a valid access token for use with the REST API command
  • The ability to perform authenticated HTTP POST requests, e.g. by using cURL or node-fetch.
  • The ability to parse HTTP responses
• Providing a simplified path to executing autolaunched flows directly from the CLI would make this functionality more accessible to various users.

Who might use this?

• DevOps Engineers could use flows for post-deploy operations in CI/CD pipelines.
• Developers could use flows to prepare, or reset the state of, scratch orgs during development.
• Admin Power Users could use flows to automate administrative chores.

Proposed Syntax

$ sf flow execute --help
Execute an autolaunched flow in the target org.

USAGE
  $ sf flow execute -o <value> -n <value> -p <value> [--json] [--api-version <value>]

FLAGS
  -o, --target-org=<value>   (required) Username or alias of the target org. Not required if the `target-org` configuration variable is already set.
  -n, --name=<value>         (required) API name of the autolaunched flow being executed.
  -p, --payload=<value>      (optional) Set as an inline JSON object representing the input variables for the flow.
  -f, --file=<value>         (optional, alternative to --payload) Path to a file with a JSON object representing the input variables for the flow.
  -w, --wait=<value>         [default: 0 minutes] Number of minutes to wait for the autolaunched flow to complete.
      --api-version=<value>  Override the API version for this command.
      
GLOBAL FLAGS
  --json  Format output as json.

DESCRIPTION
  Execute an autolaunched flow, optionally passing in a JSON object representing the input variables for the flow via an
  inline flag, a file containing a JSON object, or piped in via STDIN.

ALIASES
  $ sf flow run
  $ sf execute flow

EXAMPLES
  Execute an autolaunched flow with a direct JSON payload:

    $ sf flow execute -o my-org -n "MyFlow" -p '{"inputs":[{"key":"value"}]}'

  Execute an autolaunched flow with a file-based JSON payload:
  
    $ sf flow execute -o my-org -n "MyFlow" -f ./config/flow-payload.json

What do you think?

Specifically, I'd like to know...

• Is this idea useful?
• What would your use cases be?
• Does our proposed syntax make sense?
• Have we missed anything?

Please share your thoughts by commenting on this thread. Thank you!

[daveespo]

Can anything be done in Flows that can't be done in Apex? "Good developers don't let other developers write Flows", I always say.

[VivekMChawla]

@daveespo - It's less about providing access to things that can't be done in Apex and more about increasing the pool of people who can contribute to logic running in the org.

Don't get me wrong, coming from the ISV world, I used to feel the same way as you do about Flows. I don't think that's a fair stance anymore, especially when writing flows with a single purpose, like handling post-deploy actions or orchestrating administrative chores.

[jkranz-rk]

I don't have a specific, concrete use case for us (as an ISV/OEM), but I can see how this could enable collaboration between admins and DevOps for customer/subscriber orgs.

Something I don't see in the proposed syntax is a way to supply values to any input variables that the autolaunch flow might accept (or even need in order to run as expected). Edit: I see you have that in the proposed syntax. :)

Perhaps also worth thinking about how output variables might be able to supplied back to the CLI after its executed. Maybe only really possible if run synchronously.

[RupertBarrow]

I'm not a Flow specialist, but I have 3 extra ideas I can contribute :

• how will both system and flow errors be managed and reported ?
• it might be interesting to have an option to run the Flow in debug mode
• will this be the solution to run Flow tests ?

[jkranz-rk]

will this be the solution to run Flow tests ?

This is a good point. Record-Triggered Flows can have Flow Tests configured for them, but there isn't a way to automate the running of them. I'd consider the ability for the CLI to run a Flow Test a more important feature than running a Flow

[dschach]

Anonymous Apex is Apex run from the CLI, but it is not anonymous. It runs with user permissions.

Would this flow run as system or as user?

[mitchspano]

This is a novel idea; here are some of my thoughts:

Personas

When I consider someone in an administrator role, I don't foresee that they would be writing the flows for org AND invoking them from the CLI. This seems like two separate personas:

• The developer who wants to offload org setup things to an administrator.
• The administrator who wants to be more involved in org setup.

Both of these seem like rather niche use cases - so I am not sure this directly solves a current pain point with the CLI. This might be a "We can make it happen, so let's try to do it and see what the community does with it" kind of feature which is fine - perhaps we just acknowledge that.

Interface

** Small soap box moment here
I think the concept of a "flow Interface" would come in handy in this situation. There are many places on the platform where we want to invoke an autolaunched flow but need to ensure that it has a predefined set of input and output variables. In this case, one would imagine that the flow should have any output, and should probably not accept any input either. In Apex, it would look something like this

public interface CommandLineExecutableFlow {
  public void execute();
}

Having a way to programmatically guarantee that a flow satisfies an "interface" would offer tremendous value in this situation and could solve many other problems for autolaunched flows across the entire platform. This however goes well beyond the scope of the CLI and would require strong buy in from @alexed1 and the Flow team.

Relative Value

For what it's worth, I think the value proposition for this idea is substantially less than #2492. Running tests from the CLI solves many more problems for customers right now than running autolaunched flows from the CLI.

[GeekStewie]

There are two areas where this would be useful:

1. Salesforce Demo Orgs: I have often seen that demos have a flow (or flows) which "reset" the demo back to an initial state. This would be useful to run from command line if you wanted to trigger this for an org before deploying something else or simply just running it against one or more demo orgs. More of an internal use case.

2. Automated Testing: At the moment we test that a flow deploys to an org when part of a PR although we don't test that its still running as expected without issues. Could be good to have an option for testing added where a flow can be deployed and checked that it runs as expected. Could also be added as a flag on the sf project deploy to test the flow works in the target org after the deploy, however for both of these specific tasks it would likely need a sample data load to be run before hand either as a separate command or as a data import file which is provided as a variable that be can passed in as a file path and uploaded before the execution is run.