Is it possible to lock the form in edit mode?

Reference: https://www.jotform.com/build/72377878509171

I am attempting to build a simple state machine. The code does not operate as I would have expected.

The purpose is to be able to set a flag such that it is possible to re-enter and review the form data, but not change and re-submit. In real life, the logic would be a bit more complicated than what is shown here. This is a simplified case and a rather simple state machine. 

Is this even possible to create? I've tried many (perhaps 40) different variations to get it to work. It won't operate as designed/expected.

Could you please explain more what you would like to achieve exactly? Since when I checked your conditions, there is a conflict between them.

You're inserting the result into the field that you're using in the same condition. And that just can not work.

We'll wait for your response.

Thank you!

"...and that just can not work."

Very confused by this statement. This is what all computer hardware and almost all software already does. So, if simple procedural code and logic can not work.... Well, I'm confused.

What I am attempting to do is exactly what is described above. Let me put it in a use case.

A. Submitter enters form, fills it out, and submits.
B. Submitter re-enters form, makes changes, and resubmits. (Repeat B. an undefined number of times until C.)
C. Administrator (or software) at some point in time sets a lock (flag) so that the form may no longer be changed.
D. Submitter re-enters form, makes changes, but cannot resubmit. (Repeat D. an undefined number of times until Z, if ever.)

Z. Submitter asks for an override, administrator resets lock (flag) so that form may be changed. Return to "B." above.

On the form, the submit display is hidden when the lock flag is set.

I've experimented with a large number of means to create sequential logic, and have been prevented at every step, even through several levels of variable abstraction. It is as if the code refuses to remember or even consider the current states that are set in the form, which makes no sense at all. 

Another way that I might have asked this same general question would be: how can I create a counter so that on each entry/submission of the form, the counter is incremented. So, on first use, the default is set to 1. On the second entry to the form, the counter is incremented to {counter}+1 or 2. Etc. Piece of cake, right?

Condition a and 2 that you have set are creating a loop. It is changing the value back to Off.

How to Show or Hide Fields Base on User's Answer

To hide the submit button I would suggest you to add a hidden field to the form with the options On and Off and set a condition to hide a submit button if the option is set to On. A default value of that field can be set to Off. 

The hidden field will not be shown on the form. With the admin access to your JotForm account you will be able to see the hidden field and when necessary change the option to On (step C). At any time the admin can change the option back to Off (step Z).

Inside of this guide, you can find how to edit submissions made on your forms:

How to Edit Submissions Made on Your Forms

I just realized that my solution will not work, because the admin will not be able to see the submit button and submit the form. The changes made on the form will be saved only when the form is submitted. 

Instead of hiding the submit button, I would suggest you to disable all other fields on your form, when the admin set the hidden field option to On. This will prevent your users to edit submissions, which will give you the same result as hiding the submit button. 

How to Enable/Disable Fields Using Conditional Logic

I see no loop. 

I do not know what you mean by Condition "a."

You are correct, no one would be able to set a flag and then submit to save it.

The point is for individuals to be able to see the data, so no, we won't be hiding the data fields.

So, let me return to the question. Is there a way to create a state machine. Use whatever example you wish. For example, show me how to implement an incrementing counter.

I made a typo. Conditions 1 and 2 are creating a loop.

With the second solution I provided the fields will be disabled and the user would not be able to change previously entered data, but the data would still be visible. 

Here is a demo form: https://form.jotformpro.com/72415478118964 

If the flag option is set to On, all other fields on the form will be disabled.

Feel free to test it and clone it. 

You can use Unique ID field for incrementing counter. However, it will only count the new submissions. The counter will not increase when the submission is edited. 

How to Add Custom Unique IDs to your Form Submissions?

We also have a submission counter widget that you can use. 

Submissions Counter

Again. There is no loop.

If {setFlag} is "Off" neither test for condition 1 nor condition 2 are met. Nothing should happen.

If {setFlag} is "On" and {flag} is "Off" then the test for condition 1 is not met; nothing should happen for that condition. The test for condition 2 is met and {flag) should be set to "On". 

This change should trigger condition 1 (continued, below), but the test for condition 2 should never be met again.

If {setFlag} is "On" and {flag} is "On" then the test for condition 2 is not met; nothing should happen for that condition. The test for condition 1 is met and {setFlag} should be set to "Off".

This change would not meet the test for condition 1 or condition 2 and no further changes should ever occur.

So, 
In the event that {setFlag}/{flag} are Off/Off or Off/On, nothing should happen;
In the event that {setFlag}/{flag} are On/Off, the flags should be set to On/On; (and then)
In the event that {setFlag}/{flag} are On/On, the flags should be set to Off/On.

Said differently, if the form is entered with {setFlag}/{flag} set to On/Off, condition 2 should trigger, leaving {setFlag}/{flag} are On/On, which should then trigger condition 1 leaving {setFlag}/{flag} set to Off/On. Nothing further should take place.

No loop. Very simple state machine. 

You are attempting to solve an example. Which you have accomplished. The general problem/issue remains. Like I said earlier, what I am attempting to do is substantially more complicated.

Again, can I create a state machine? If so, how? If not, I'll quit looking for a way.

Thank you for explaining your requirements further. However, we would like to apologize for any inconvenience, the counter you mentioned to count the number of times the form has been edited is a feature that is not available. A similar request has already been submitted for that feature — How-to-add-a-limit-on-edit-link-to-how-many-times-user-can-edit-their-data

As for the conflict in the condition my colleague, BJoanna, was explaining, changing the state of a field that is part of the action rules of the same condition is not possible that is why the condition you set in your form is not working.

Having said all that, I believe there is a workaround that may suit the requirements you described in your first reply in this thread.

A. Submitter enters form, fills it out, and submits.
B. Submitter re-enters form, makes changes, and resubmits. (Repeat B. an undefined number of times until C.)
C. Administrator (or software) at some point in time sets a lock (flag) so that the form may no longer be changed.
D. Submitter re-enters form, makes changes, but cannot resubmit. (Repeat D. an undefined number of times until Z, if ever.)

Z. Submitter asks for an override, administrator resets lock (flag) so that form may be changed. Return to "B." above.

Suppose the submitter already submitted the form (A), if the submitter would like to make changes, the submitter needs to access the form in edit mode to view the form filled with previous answers and resubmit it (B). The submitter can do this until the administrator decides to lock the form that will hide the submit button on the form in edit mode (C). This will not prevent the submitter to make changes to the form, but will not be able to submit it (D) unless the submitter asks the administrator to unlock the form (Z).

In your example, I can only assume that the edit link the submitters can use is sent via email autoresponder as explained in this guide — How-to-Let-Users-Update-Their-Form-Submissions-at-a-Later-Date

There are two edit link formats:

1. https://www.jotform.com/form.php?formID={formID}&sid={id}&mode=edit

{formID} is series of numbers you see on the form's direct link — https://form.jotformpro.com/72416923856969 and {id} is the submission ID of the submission.

Here's how you can create the first link that can be included in the content of your form's email notification/autoresponder.

2. https://www.jotform.com/edit/{id}

Unlike the first edit link, the second link is easier to create. You can type it as it is or use the same steps in the screenshot above to add the {id}.

I have explained this to show you that you can provide different edit links for the submitter and for the administrator.

Then with the help of the Get Form Page URL widget following this guide — How-to-Show-or-Hide-Fields-on-Edit-URL, you can hide or show the lock field (flag) of the form based on the URL used to access the form. Then, based on the state of the lock field and the URL used to access the form, you can hide or show the submit button of the form.

You can have the first edit link sent to the administrator via email notification — Setting-Up-Email-Notifications and the second link to the submitter via email auto responder — Setting-Up-an-Autoresponder-Email

Here's a sample edit link that will be sent to the submitter — https://www.jotform.com/edit/3799398898185952521

Notice that the submit button is hidden on the form.

Changing the status of the Lock field in the edit link for the administrator from "On" to "Off" will show the submit button in the edit link of the form for the submitter.

Here's a sample edit link that will be sent to the administrator — https://www.jotform.com/form.php?formID=72416923856969&sid=3799398898185952521&mode=edit

Here's the direct link to the form I used in my example — https://form.jotformpro.com/72416923856969

Feel free to clone the form to your account and use it as a reference — How-to-Clone-an-Existing-Form-from-a-URL

Below are the conditions created for the workaround:

I hope this helps. Otherwise, please let us know.

Part 1

Reference: https://www.jotform.com/build/72416883817163

The issue seems to be more global than indicated. For this combination, everything works as planned.

If you click the "On" button for flag 1, flags 2 and 3 will be set to "On" and all three will remain set.

If you enable the third condition, then click on the "On" button for flag 1, you will see that flags 2 and 3 will be set to "On", flag 1 will be set to "Off" and then all three flags will be returned to clear.

I'd call that a bug. It does exactly what it should, then it destroys the state/data.

Part 2

We have implemented something similar, by passing the lock variable to the form over the API. Your trick is interesting, though, and I can probably make use of the idea for some other things.

Part 3

In the short term, I can take care of the logic/state-machine on the website on which the form is embedded. This is clumsy as the state machine now requires exit and reentry to the form. It would be so much easier if this just worked like any normal software/hardware language. 

I should note that there are other oddities. With condition 3 disabled, set this up:

Turn On Flag 3, then Flag 2, then Flag 1. Then turn off Flag 2. Poof goes Flag 3. I would call that bizarre behavior.

Turn On Flag 3, then Flag 2, then turn off Flag 1. Poof go Flags 2 & 3. I would call that bizarre behavior.

I have been checking your conditions and noticed there are some conflicts between them, for example, you have set the conditions like this: 

Based on the behavior you have noticed:

Turn On Flag 3, then Flag 2, then Flag 1. Then turn off Flag 2. Poof goes Flag 3. I would call that bizarre behavior.

This happens due to the condition you have set up: 

As the Flag 2 is set to Off the selected option in Flag 3 is removed since the condition is not met. 

Turn On Flag 3, then Flag 2, then turn off Flag 1. Poof go Flags 2 & 3. I would call that bizarre behavior.

This is the same behavior like the condition above, since there is a condition that inserts the On option to Flag 2 and Flag three based on the selection made on the Flag 1 field, if the condition is not met, the already selected option in Flag 2 and Flag 3 will be removed.

The same happens when you edit the third condition, if the Flag 3 is Off the selection made in the Flag 1 will be removed and so the selected options in the Flag 2 and Flag 3 will be removed as per the condition. 

If you would need to keep the selections, you would need to add some conditions, for example, if Flag 3 is Off then insert On in Flag 2, but do note that the conditions may misbehave if there is any conflict between them. 

I hope this helps.