Using Enums to represent a stage / lifecycle - what is the best way in Appsheet?

[dbweb]

The records I'm tracking all have several stages of a lifecycle they go through, like a flow chart. 

I started out with an Enum to represent each stage, but now that I'm working on each input form, I'm not sure if this is the best approach. 

The Stages all have names that represent the state of the record. But when the users select a record, I'd like them to have a more friendly label. 

Example:

When the user moves a record to the "Unqualified" stage, I'd like them to select "Ready to Qualify". 

Is that possible with AppSheet? Would it be better for me to rename/redefine my Stages like "Ready to Qualify"? 

Another question I have around this Stages Enum is that for some Stages, I need to require certain fields on the Edit form, but only if a particular Stage is selected. 

For example, if the user chooses Stage "Closed Lost" then I need to require them to enter the reason why. 

Would I enforce this on the specific reason field in the data table, on the "Require?" with a formula matching the Stage? 

I have around 8 different Stages in my Enum, is there a way I can limit this to only 2 or 3 in a particular form? 

[dbweb]

I've been able to keep users from selecting invalid Stages by adding a conditional "Valid If" based on "Context("View")"  checking for the View name.

While this works, I still have all these Stages that users will and should never select on the Form. 

I see that the Enum can have a Base type of Ref, and that this Ref can be a Slice.

Does anyone know if I could put the Stages in a Data Table, create a Slice and Ref this, and then do a row level filter on the Slice to limit the available Stages? 

[Suvrutt_Gurjar]

---

@dbweb wrote:

and then do a row level filter on the Slice to limit the available Stages?

---

If you could give a few examples or share screenshots with pseudo data , the community could give better suggestions. It is not exactly clear what conditions you wish to use  to filter certain stages for the user.

In general , you could explore using  a valid_if in the enum to restrict stages based on other conditions that you wish to evaluate.

For example

IFS( Condition 1, LIST( "Requirements gathering",  "Preliminary discussions"),

        Condition 2, LIST( "Deal Proposal",  "Under Negotiations"),

        Condition 3, LIST( "Closed won",  "Closed Lost", "Deal canceled)

       )

[dbweb]

Thanks for the reply, here's a more specific example.

Users need to update fields in Stages. 

Each record will start in Stage 1, then move to Stage 2, then Stage 3 then be Closed Won.

They will use different Forms for each Stage. 

For example, the record starts at Stage 1, they will use the Stage 1 Form to update it and then it will move to Stage 2. The Stage 2 form will be used for Stage 2, etc

On the Stage 1 form, users can either select "Stage 2" for the record to move forward, or "Closed Lost". 

I'm using a "Valid If" now, and while that prevents the wrong Stages from being selected, I have 11 stages and the UI looks sloppy. 

My ideal here is to only present the users with options that are valid for them to choose. 

So although I have 11 different valid Stages for the Enum on my table, in specific views I want the users to only see available for selection a subset of these values.

[dbweb]

The condition I need to use to limit the available Enums is just the view name. 

However I can only get this to limit the valid values, and I cannot see how to limit the available values for display purposes. 

In my example above. Stage 1 Form should only show the user "Stage 2" or "Closed Lost" but instead it always displays all Enum values. 

[dbweb · Accepted solution]

Okay, I think I figured it out. 

Since I had a list of defined Stages, my brain was set on using an Enum.

I've now moved the Stages to a read-only Data table, created a slice that row filters based on Context Form/View name and now it correctly limits my Stages on a per-form basis!

[Suvrutt_Gurjar]

Thank you for the update. Nice to know you figured it out. 

[Marc_Dillon]

---

@dbweb wrote:

However I can only get this to limit the valid values, and I cannot see how to limit the available values for display purposes

---

Valid_If should accomplish both of those. I suspect you had the "auto-complete other values" option still turned on for the Enum column.

---

@dbweb wrote:

a slice that row filters based on Context Form/View name

---

I do not think this is a good idea. You'll run into trouble if you ever want to update these records from a Bot. I also don't feel comfortable relying on the slice always re-evaluating on a view change. Not sure if that's just because it's not something I've ever done with Appsheet (over 5 years now), or if there's actually a valid reason for that, but it just feels weird/wrong...

Here's what I would do:

You've already got the separate table for your stage options, great! So then change the Enum column to a Ref to this new table.

Then add in new columns to that new table that describe which stages are valid next. Like if your stage ids are 1,2,3..., you could have a column that holds a comma-separated list of valid values that a stage can go to next, being 2,3,4... or whatever. Then you can use a FILTER expression in the valid_If to show the appropriate next possible values.

Alternatively, provide a separate [order] column that describes the order, then your valid_if could more simply show only stages that are greater [order] than the current, or +1, etc...

There are probably several other clever options in this way.

Basing it completely on the context(view) just kind of locks you in to those specific forms, and is not very scalable.