0

enter image description here

enter image description here

Hello! I'm wanting some advice on how to best go about combining the two branches here in the flow. I have a boolean formula that is just "ISNEW()" that determines which branch to take in the first decision element.

On the Updated side, it checks to see if the "PhotoURL" field is changed and populated, and it updates another field, then moves on the check if the "Phone" field is changed and populated, and updates another field. When it's new, I'd like for it to check for those fields as well and update the relevant related fields. Is it possible to do? Or does it need its own path?

This is not our real use case. Just something simple for me to post here

Improve this question
1

2 Answers 2

Reset to default
1

Instead of using separate paths for new vs changed, create a Boolean formula resource for ISNEW() and use that formula in every decision element where you need to distinguish new vs. changed.

So your Populate Country assignment would branch off a decision where IsNew = TRUE, whereas your photo-related decisions would check IsNew OR changes to the photo-related fields.

Improve this answer
2
  • I am using the same approach for my autolaunched flow, however i have a doubt - (1) if it works in autolaunched flow (2) if yes, then when I am debugging it for create record, why it is capturing value as false in ISNEW() formula variable? Commented Apr 10, 2024 at 8:44
  • How are you invoking the auto-launched flow? From a button or something else? Commented Apr 10, 2024 at 15:37
-1

This is why there are 2 different types of Record Triggered Flows. You should use 2 different Flow types.

Only When a Record is Created Only When a Record is Updated

Don't use the option that includes either. This is also MUCH easier to maintain else if you are nesting IsNew() all over your different Flows it's impossible to know what's where.

Improve this answer
2
  • It all depends on the system in question, so I disagree with using this idea as a general rule. There are many reasons to keep it in a single flow, such as not duplicating business logic across different flows. A good example we have is there are a number of fields with complex business logic that need to be initialized on creation as well as change of record type. If you have different flows for insert/update, then you're duplicating this logic across them. Commented Sep 8, 2022 at 0:43
  • Not necessarily. I'd move the logic like that to an autolaunched (sub) flow where it's only maintained once. Then you are still tracking the data flows for record creation and record updating more easily. When mixed in the middle of diff flows asking for trouble. Commented Sep 8, 2022 at 14:29

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.