I am creating a Custom Form and I have a field that needs to be required if some of the previous radio buttons on the form are checked and not required if other buttons on the form are checked.
The field in question should be visible/available regardless of what request type is selected via previous radio buttons but must be required for only some of them.
I was hoping there was a way to do this via field logic but that is not the case. The only way I can see to do this is to create two fields with slightly different names, having one of them be required and one not, then adding display logic to them. However, that would make reporting on the field more challenging. I'm hoping there's a better option.
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Hi,
The way I have overcome this in the past is to create two separate fields (one required, one not) driven by display logic, exactly as you have outlined. And then create a third calculated field that returns the values entered into the first two fields i.e., CONCAT({DE:Field 1},{DE:Field 2}).
You can use the calculated field in your reports to show whatever values are entered into field 1 or 2.
Does that make sense? Shout if you have any questions.
Best Regards,
Rich.
You are correct that you can't make a field that you want to always show be required or not based on a different field's answer. If you don't want to make the slightly different field, which I agree with you on, you'll need to make it required and I recommend in the tooltip or in field name to specify when it's optional so users can know to put N/A or a dash or something (if it's a text field?). If it's a dropdown, radio or checkbox field, then you should add an 'N/A - for XYZ options ONLY' kind of answer option.
If you found this helpful, please mark correct to help others : )
Hi,
The way I have overcome this in the past is to create two separate fields (one required, one not) driven by display logic, exactly as you have outlined. And then create a third calculated field that returns the values entered into the first two fields i.e., CONCAT({DE:Field 1},{DE:Field 2}).
You can use the calculated field in your reports to show whatever values are entered into field 1 or 2.
Does that make sense? Shout if you have any questions.
Best Regards,
Rich.
I think she was trying to avoid two separate fields but I like the workaround for how to still make it clean in returning the values for both in a report
The reason for avoiding two fields was that it makes reporting difficult. . . . This problem goes away if you have a third calculated field that references them both because you now only need to include one field in your report, if that makes sense.
Yup I get you. Love it.
Views
Replies
Total Likes