I have a business process which has several different paths, depending on the situation. I have built an ontolgy to track the outcomes of the process. I have an action to update the object that has a series of dropdowns which should be different depending on the situation. I have tried to do this two ways:
Used “String Entry” widgets in workshop to manually create a form.
This was good in that it allowed fine control over the drop downs.
This was bad because I could not find a way to load current values for objects, so it worked for inserts, but not for updates.
Use Inline Action Form or Table with an action that has all drop down options
Good because it has nice integration with workshop and can update easily.
Bad becuase it does not seem possible to limit drop down options from the client side, all drop down options are available, and can lead to bad data entry.
Use Inline Action Form or Table with separate actions with drop downs for each scenario
Allows fine control
If i want to have an action log, now i have to maintain a different action log for each scenario.
Is there a way to control drop down options for inputs to an action in a way that supports updates. In an ideal world, this would be a configurable lis of options in the workshop config, or a way to populate text input widgets from an action. Is there a right way to do this?
One idea that I come back to in some of these complex business process/data entry patterns is to ontologize the process itself. So rather than hard-coding the “logic” of the process (i.e. what values are valid at what stage of the state machine) into the Action form configuration or the application front end, you can set up an object type that represents the state machine for your process, the valid outbound transitions, the lists of allowed values, and other metadata that your actions and UI can use as context for the given user.
This doesn’t directly solve your question, but by encoding your process as data in the ontology, you can unlock patterns that look like (oversimplified):
Object A in State X
Get State X from the State Machine object type and pass Object A and State X into the action form
Populate the dropdown from a property on State X
Working with this pattern basically gives you another layer of abstraction in your data model and makes building with Action Forms or move complex Workshop form layouts more flexible.
Thanks, that is interesting, I could see how that would help.
As I looked at this I realized that the “Override” functionality is key to being able to achieve what i am trying to achieve. E.g. Based on a user selected category, we can make section or field in the action form visible or invisible, and can change the allowed and default values based on the selection. By doing this, I was able to achieve the results I was looking for with one action.
That makes sense - if you are looking to hard-code conditional logic in forms, then using the overrides is the way to go. In addition to controlling the default value, dropdown options, visibility, and required-ness per parameter, you can also control visibility of entire sections of the form at a time.