set timer on interface to auto submit?

This sounds like a case where requirements are overreaching and will cause much more development time, maintenance and hassle than may be necessary.  Is there any reason the user cannot Submit to confirm their selection?  Do they expect the interface to change immediately once their dropdown selection is complete, or do they want to make a selection and close the window and the process moves on behind the scenes?

If they expect the interface to change immediately, you could create a wizard type interface and handle this within the same form, such as:

a!localVariables(
  local!option1,
  local!option2,
  {
    a!dropdownField(
      label: "Option 1",
      showWhen: rule!APN_isEmpty(local!option1),
      placeholder: "-- Select --",
      choiceLabels: {"A","B"},
      choiceValues:  {"A","B"},
      value: local!option1,
      saveInto: local!option1
    ),
    a!dropdownField(
      label: "Option 2",
      placeholder: "-- Select --",
      showWhen: and(
        rule!APN_isEmpty(local!option2),
        not(rule!APN_isEmpty(local!option1))
      ),
      choiceLabels: {"C","D"},
      choiceValues:  {"C","D"},
      value: local!option2,
      saveInto: local!option2
    ),
    a!richTextDisplayField(
      showWhen: and(
        not(rule!APN_isEmpty(local!option2)),
        not(rule!APN_isEmpty(local!option1))
      ),
      value: {
        a!richTextItem(
          text: "Done!",
          style: "STRONG",
          size: "MEDIUM"
        )
      }
    )
  }
)

Otherwise if the process must move without them submitting, an exception timer would be required and it cannot chain them to the next interface - I would not recommend this approach, but if you allow them to select an option, and not submit, you would need to handle the data persistence with a!writeToDataStoreEntity() on the dropdown or any other field they can toggle, so their selection is immediately stored to the DB.  Then remove the Submit button completely.

Then you will need to set an exception timer, and you will have to weigh the timing where it's long enough that they have time to make their selection, but quick enough to keep the process moving.  This will cause you issues since the timer begins at task assignment, not at the time they accept (open) the task.

Again, possible in theory, but not a UX like I would suggest - or let the business suggest without a set of disclaimers from a maintenance and process perspective.

This sounds like a case where requirements are overreaching and will cause much more development time, maintenance and hassle than may be necessary.  Is there any reason the user cannot Submit to confirm their selection?  Do they expect the interface to change immediately once their dropdown selection is complete, or do they want to make a selection and close the window and the process moves on behind the scenes?

If they expect the interface to change immediately, you could create a wizard type interface and handle this within the same form, such as:

a!localVariables(
  local!option1,
  local!option2,
  {
    a!dropdownField(
      label: "Option 1",
      showWhen: rule!APN_isEmpty(local!option1),
      placeholder: "-- Select --",
      choiceLabels: {"A","B"},
      choiceValues:  {"A","B"},
      value: local!option1,
      saveInto: local!option1
    ),
    a!dropdownField(
      label: "Option 2",
      placeholder: "-- Select --",
      showWhen: and(
        rule!APN_isEmpty(local!option2),
        not(rule!APN_isEmpty(local!option1))
      ),
      choiceLabels: {"C","D"},
      choiceValues:  {"C","D"},
      value: local!option2,
      saveInto: local!option2
    ),
    a!richTextDisplayField(
      showWhen: and(
        not(rule!APN_isEmpty(local!option2)),
        not(rule!APN_isEmpty(local!option1))
      ),
      value: {
        a!richTextItem(
          text: "Done!",
          style: "STRONG",
          size: "MEDIUM"
        )
      }
    )
  }
)

Otherwise if the process must move without them submitting, an exception timer would be required and it cannot chain them to the next interface - I would not recommend this approach, but if you allow them to select an option, and not submit, you would need to handle the data persistence with a!writeToDataStoreEntity() on the dropdown or any other field they can toggle, so their selection is immediately stored to the DB.  Then remove the Submit button completely.

Then you will need to set an exception timer, and you will have to weigh the timing where it's long enough that they have time to make their selection, but quick enough to keep the process moving.  This will cause you issues since the timer begins at task assignment, not at the time they accept (open) the task.

Again, possible in theory, but not a UX like I would suggest - or let the business suggest without a set of disclaimers from a maintenance and process perspective.