Knacks Rules are built for power as well as protection. I’ve had an issue with the Conditional Field option that may be helpful for creating/editing unique identifiers for records. Such as invoice and order numbers.
I created a complex formula to create a unique Purchase Order Number 31456-RKH182. 31456 is the auto increment, RKH is the employee requesting the order, 18 is the year and 2 is the month. I needed to assign this formula result to the Purchase Order Number field in my record BUT I wanted the end user to be able to edit this unique number. To accomplish this I had to use a special sequence of Knack functions. Otherwise it would not work.
- Create a Text Formula field called ‘Purchase Order Generator’ to generate the unique alpha numeric Purchase Order
- Create a ‘Purchase Order field’ (short text)
- Put the editable ‘Purchase Order field’ on my ‘Purchase Order Edit Form’
- Back to the ‘Purchase Order object’ and open the ‘Purchase Order field’
- Create a Conditional Rule ‘when the Purchase Order is blank then Purchase Order =Purchase Order Generator’
- Done
Now Knack creates a unique identifier for my Purchase Orders AND the end user can edit it later if changes need to be made. The ability to edit a conditional field depends on the order in which you perform Knack tasks (from list above) #3 Add editable Purchase Order to the Editable form #5 Create the conditional rule to auto assign the Generated Purchase Order Number to the Purchase Order field.
If you create the Rule first, the field will not be available from the pick list for addition to your Edit Form.
Okay...I've tested and this work-around definitely works. And it's a critical work-around for my application. So...Knack Team...if you ever close this loophole, PLEASE notify us and help address the underlying issue of being able to override and edit a conditional. Thank you!
Very observant.
In our case, we apparently turned a problem into a solution. Knack simply leaves the precaution up to the user. If you want to 'abuse' the conditional field functionality to allow a 'admin' user to edit conditional field data, this is a solution. That's the beauty of Knack. It's not so rigid that you can't be 'creative' with it.
I would agree that it could cause an issue if the developer isn't cautious with it's use. As with any 'special work around', this method should be documented and in our case works well. It was really a 'life saver' in regards to our 'auto invoice number generator'. It is predictable and controllable. It allowed us to use the auto increment, formula field and conditional field combined to generate very create numbering systems that can still be edited (if necessary) by our office staff with admin privileges.
I just want to throw a big warning out there that this is not a solution and is actually the result of some missing checks on Knack's side, which tech support has mentioned to me that they need to fix. A conditional field simply should never be able to be used in this manner, and the fact that it can be is a bug. I'm not sure if it's still supposed to be the case that the conditional field can be set upon record creation, which is possible through manually addition of a record in the Builder and through a form's Record Rules.
I had done this unintentionally with two fields, and at some point I was manipulating and copying the view, I noticed that one of these fields was no longer copying over with my view. I then realized that it was no longer an insertable field item, after which I found myself having to rework that piece of data. Fortunately, it was at a point where it wasn't a giant issue.
Thank you! This solves exactly the problem I'm having and have been trying to find a workaround for weeks.
Inserting the modifiable field into the page first and then adding a conditional rule.... perfect!!