One Cascade based on Another

[Shawn Keene]

Hi there, I’m trying to see if I can base one cascade based on selections made in another.

I’ve built a very simple support ticket tracking list. To classify the type of issue, it contains one set of cascading selections similar to the attached example (TicketTypes sample.png) although my real list of cascading selections has 48 rows in it with 4 types of “Level 1”.

I also have another cascade on the same list allowing for marking the status and type of resolution used to close the ticket. That list looks like the attached example “ResolutionTypes”. If the ticket is open, there’s no level2 to even choose from. But if you’re making the ticket is “closed”, you choose the resolution as you can see that example.

Finally, my ask: I’ve been asked to set it so that the resolution is based on the earlier chosen “TicketType”. For example, to prevent a resolution of “Problem Fixed” from being used unless the earlier cascade had a selection involving a problem that needs fixed. Or for another example, to only allow “Saved” resolution to be used if the ticket was regarding a request to cancel a service.

I hope this makes sense.

Maybe my best option is to just greatly expand my original list of 48 types to include all the variations of resolutions for each one, but I think that would probably not be optimal.

My gut feeling right now is that using the alternative “pipe delimited” version of the cascading configuration list would be better. For each type of request, I could have a “Level4” that pipe-delineates the resolutions you could have for that type of request/ticket. That way I keep that original list as only having 48 rows, but each one can definite it’s resolution options as well.

I think my best option right now is to setup another set of lists for testing this out without screwing up anything in production lists. But while I work on setting that up, I’d love any feedback about how to accomplish this goal. Thanks, and thanks for making this insanely great tool available!

• This topic was modified 4 years, 4 months ago by Shawn Keene.

Attachments:

1. 

   ResolutionTypes-sample.png
   

2. 

   TicketTypes-sample.png
   

[Alexander Bautz]

You could set up the second casc to be called manually like show here – wrap it in a function and have a rule trigger this function when you close the ticked – rendering the correct options (you must use the filter option to find the correct values).

I think however that using the pipe delimited options will be a more reliable approach.

Alexander

[Shawn Keene]

I was about to ask if I could do a hybrid approach from the source list, but I just did some experimenting and it appears it does work that way. So my source list still has the same number of rows, but I added two more columns to specify the available status options and resolution options for each row. Status will always only allow either Open or Closed.

I attached a screenshot showing what I think is pretty successful test so far!

I think the last two pieces I need to work on are:

a) Hide the Resolution choice box if the Status isn’t “closed”
b) Require a selection in the resolution choice box if the status IS “closed”

I think I can accomplish both with rules that check on form load/change, I’ll be trying that next.

Thanks for your help so far. I don’t think I need more assistance at this stage but I wanted to share progress as I go.

Attachments:

1. 

   Screenshots.png
   

[Alexander Bautz]

Thanks for the update – you should be able to set up a rule on the Status field to show or hide the Resolution field.

Let me know if you have any questions.

Alexander

[Author]

Posts