#Flownatic0 diskutieren mit

Is your question about how to exclude the triggering record from the collection? If so, you can simply add another condition: id != $Record.id.

This will ensure that the Opportunity which triggered the flow is excluded.

I am first going to admit that I don't use many validation rules that are attached to objects. The reason was that I didn't understand them when I first set things up back in the classic days. And the next reason was that they always got in the way of integrations or automations because I didn't (or couldn't) work it into our design. Looking at all your cool contract validation rules (we don't use those but we have plenty of spider custom objects that sit on top of standard ones and must be "right" for things to work) I probably should have been making them part of all our new customizations. Perhaps I will reform my ways.

On the other hand, I learned to use flow back in the classic days becuase the classic UI frankly simply sucked and we had to have flow to get enough work done in a day. I presented my first UI flow at Dreamforce 2011? in the last hour to exactly (not quite) nobody. Lol. But we have used flow to speed data entry for a very long time. (We had that the Program Management Module supplies in terms of recording participation years and years ago using flow.) As validation within flows grew, so did our use of validation inside flows. Validation on your input fields of flow is so important. And with conditional visibility, you can not only validate the final field values but show colored warnings until the input data gets better in the flow. And we've done any logical checking right there with conditional visibility or decisions warning on the screen flow (State required! Contact location doesn't match service location! or whatever).

I have looked at but not adopted because I don't see a reason yet the new record triggered screen messages. (You could do something similar with a hidden component that watched your data and popped up a flow modal for a long time now.) I think its a very cool ideas although it has a lot of potential limits since the user has to be there. However, I have architected all our systems to avoid this forbidden type of interaction for so long that I don't typically think of it. Instead, I have a flow embedded in the page so that I can talk with the user and get the data to be right.

Like you, I have conditionally visible things to prompt the user to add missing data, whether it's on the page, in the flow, or (as you cleverly are doing) in a "explainer" field that is read only and possibly conditionally visible.

I've also used dashboards that we review monthly to find data errors or data incompleteness. (so called "Wall of Zeros").

All this said, I still think validation rules have a very important place within SAlesforce (even though I am not a good practitioner at the moment).... Anything that will break your system or allow sending out bad email to a constituent through automation should be validated from the start in a good architecture. Otherwise trust may be violated. So I liked that you showed validation on the contract object. These often have automations or systems attached to them.

Here are some of my system-driving custom objects that deserve a bunch of carefully thought out validation rules:

o Sub-Services: these are our "entitlements" and we have a flow when assigning them to make sure people are entitled based on demographic, enrollment, or time/frequency. There are a lot of "invalid" combinations of fields. These should be validated so that users won't trip themselves up.

o Donations: We say every donation must have a payment type and account source to be done. These are reflected on receipts. And yet it is possible to create closed opportunities without them. Part of the problem is that you can't set the payment type until you create the payment (which NPSP does after you create the opportunity). So validation can't actually address this one directly. The flow could but only in the case of direct user creation of opportunities, which is rare. Hands thrown up!

o Client Notes: This is our outcome monitoring object. There are some fields on it that just shouldn't occur in certain combinations. We check for them monthly, but we probably should have validation rules. That said, they are 100% created by flows so the fact that it happens is actually flow programming error and not a user error. So the validation rules would just intefere with end users until such time as we found and stamped out all the flow programming errors.

o Inventory Items: This is a custom solution inventory control system of some moderate sophistication. There are definitely no-no settings. We should for sure block creation of them in nonsense settings.

o Assessments This is our newest object and is used to create individual assessments manually or automatically against various criteria and time periods. They can be used for individual guidance or for compilation for gross outcome measures of programs and cohorts. The system we created definitely has some nonsense combination of field settings that should be blocked.

Loved the blog! And I love how you point the way to making very high use of core functions and features. Very effective and efficient for the long haul.

--Terry