9

Love the new Summer '20 release features for flow, excited to use Flows in place of Process Builder. One consideration I wanted to verify with the community. Is there a way or a best practice for debugging your flow for the "Record-Trigger" flow type? The $Record variable is used throughout but when you use the typical debug feature there is no way to insert a record id. I would prefer this so that I can develop the flow with the typical/helpful flow debugger.

At this point the only way I can think of is to activate the flow and test by manually triggering a record. This gives very little visibility and every adjustment requires a new version which isn't ideal. Any thoughts?

UPDATE/NOTE: It appears that although Record-Trigger Flows is a great idea, it may be missing a couple features in order to make it practical. For example, as a "Triggered" event, similar to good Trigger handling best practices, it should likely ONLY manage the event and call an autolaunch flow to actually handle the business logic/process. Unfortunately subflows are not accessible at this time

Improve this question
3
  • 1
    Here's an idea you can vote for: Allow $Record variable to be input so we can debug record-triggered flow
    – KC3030
    Sep 21, 2020 at 17:07
  • I'm confused by your update/note. I have a record-triggered flow, with the trigger of: a record is created, after the record is saved. I don't see a way to add a flow to this flow. Am I missing something?
    – Michael Sobczak
    Feb 23, 2021 at 16:26
  • @MichaelSobczak I believe that's why I was saying it's unfortunate that subflows are not accessible at this time. If they were then we could use this like a trigger framework and breakout our business logic appropriately. I don't want to have 10 Account record-trigger flows, but I also don't won't one overly complex one either. For a workaround my thought is to use invocable method (since actions are available) to then call a (sub) flow. Hope that helps
    – Xtremefaith
    Feb 25, 2021 at 2:35

4 Answers 4

Reset to default
3

I put an intentional fault (like creating a record without a required field) into the flow as the last step while I'm developing so that when I activate and trigger the flow with record update, it will send the full flow debug log to my email.

Once all is looking well I remove the fault and activate working version. Unfortunately using debug logs in dev console just don't show enough information and this will send lots of emails potentially but it's the best I can come up with for now!

Improve this answer
2

What I did (in my sandbox) was set up a trace flag for a user (me) to create a debug log (Setup -> Environments -> Logs -> Debug Logs). I also set the Debug Level for Workflow to Finer (Info wasn't very helpful). Then when I changed a record to trigger the process, I could read the debug logs in Setup.

Improve this answer
0

At the moment, I'm triggering my flows with a process builder automation (auto launched flow), then I switch it over to Record-Trigger once it's working. If there is a better process I would like to hear.

Improve this answer
1
  • 1
    How are you switching the flow type? The type can't be changed in the flow's properties. Are you re-creating the flow from scratch once you're done testing?
    – Garywoo
    Sep 24, 2020 at 20:42
0

I know I'm late, but you do this by choosing to save it as a new flow. I do this as well as it's the only way to test it. The annoyance is that all $Record values have to be reassigned.

Otherwise you should build it in a sandbox where you can muck it up as much as you want, then deploy it when you determine it's working properly.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .