How do Field States work

Home Forum Managing Stage / Role Field Access How do Field States work

This topic contains 8 replies, has 0 voices, and was last updated by  Peanuts890 10 years, 8 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #303


    Doing my first application having gone through tutorials and videos (excellent)

    My workflow, behaviours, notifications all appear to work okay, however I can’t get my head round the Stages and roles for field states. My application is fairly basic with the form split in to three basic areas (roles), data entry, primary approval and secondary approval. The stages are more or less the same plus an approval stage and rejected stage. I am trying to use the read only, disable, hide and normal states for the objects to limit the access depending on what stage you are at. I can get them working correctly in the form preview feature however when I use the draft mode, the state of the fields appear to have changed.





    when you are previewing the form, look to the top left title where you will also see the ‘stage’ and ‘role’ that the form is in when you are previewing.

    when you are running the form in ‘draft’ mode, it will then be following the rules you have set on the form for the stage and roles involved and can show differently.

    If you go to the ‘browser’ view (LH Toolbar) you can see there the ‘state and mandatory’ and where you can select the stage and role, then click the ‘STATE’ button and it will list all your objects and show you what state they are in for that stage/role and it may help you identify your issue

    When the form is first accessed it will load in the stage that you have set as the ‘default’ stage, and will load in the ALL role. when the form is then submitted, it will go into the next stage as per your workflow diagram, and in the notification you send out is where you can define the role to that person so when they access the form it loads in that next stage and in that role as per the notification. Anyone else trying to access the form in that stage will load in the ALL role.

    so basically look at the ALL role as ‘anyone else I haven’t specifically defined’ and then the users you are ‘notifying’ to , you set their role in the notify action

    By all means though, send over to us ( an export of your form and details of what is happening and what you want to happen and we’d be happy to have a look for you. ‘fresh pair of eyes’ etc



    Thank you for a quick response. I went back to square one and reset all the field states to default, then followed the user guide instructions, this time precisely. Everything looking good. I think previously I made the mistake of setting the field states for EVERY combination of roles and stages.





    I am very glad to find this discussion regarding object states in roles/stages. Though it was from 1 year ago, but this is very relevant to my problem. I currently am struggling with object state management – I am seeing objects states differences from the “browser view” (LH ToolBar, State and Mandatory, when I “view as” certain roles at certain stages), to the published form in the corresponding stage/role. After resetting a few times, I still cannot get all the objects to work right.

    For the published forms, I am able to see the form is correctly sent through the stages that I have defined in the workflow, the URLs within the notification emails also have lead the “stage owners” to the form, but some of the objects’ states on the published form just cannot be controlled as I have wished, unlike what I can see from the preview (through View As from LH menu).

    I have set all the object states based on the Tutorial’s recommendation: “State Priority”, with 4-level of object states review and set up in sequence. At this point, I am wondering if there is anything else I am missing, or if there are any other special tips regarding setting the object states, and how to make sure that I haven’t left out anything critical, as this is really a very tedious and time-consuming process. We are currently using v. 1.18. Thanks.


    Aside from the advice given above, I can suggest two other things to help:

    1) In the properties for an object next to the state drop-down there is a small box with “…” in it. This is the state overview button. Click it to see a chart for the state of that object in every possible combination of roles and stages.

    2) If you will be changing the state of an object, avoid using “default” as a setting. Use Normal instead. Default will always revert back to the last state. Normal makes it editable.



    Thank you, Dennis, what you have suggested have always been in my consideration in setting up the object states. Preview of the pages by stage/role also verifies my set up plan, but my question is why there are state differences between the View As Role/Stage preview and the actual published form in the workflow stage/role. Thanks.


    Of course there should not be. My inclination is to suggest that in the live instance perhaps you are not in the stage/role that you think you are. The best way to test this is to place a field for stage and one for role and when the page opens set the fields with stage and role. If that proves that you have all of the settings correct and are in the correct role and stage, please create a new support inquiry and attach the .pf file of the form.



    Thanks again, Dennis! Yes, the display of the current stage and role does help me in understanding where the problem could be for the published form – I do have the correct stages (through the receiving of notification emails), but the roles seem to be “unspecified” for all the stages, instead of the ones that I was assuming them to be. I have defined Email Field for workflow notifications, instead of defining “workflow roles”, is this the reason why the roles cannot be specified, which then caused the problem to the object states? Please be kindly advise. Thanks.


    You must define roles for the workflow (in the workflow panel on the right side). The notifications must also specify the role (in the “General” tab of each notification). If that is done the user will be identified in the role when they enter the instance via the link in the notification.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.

© Copyright 2021. All rights reserved.
Contact Us