We’d like to use the stages element in a more complex situation. Currently, a project may be in 1 of 3 pipelines, all with their own stage names. Currently, it appears that the stage element must come from a single option select field. I know we can create multiple fields and then create visibility conditions so that the appropriate stage element shows depending on what project category is selected; however, it would be more elegant (in my opinion…) to have a set of tables to define project categories and project stages, and then linking everything together. Hoping my description makes sense…
Has anyone run across a more complex type of staging arrangement with their projects and did you implement any kind of clever work-around to get the traditional staging element to work but without the need to create multiple elements in the builder and then hide them based on conditions?
Separate stage fields, with a pipeline element for each that conditionally displays.
One stage field that has all the possible values in it, but in the pipeline settings you put conditional visibility onto the individual field values, so only the appropriate ones display for the current project’s pipeline type. This is the simplest option and most elegant.
This last option doesn’t really work: A project links to a Pipelines table. Helpful for tracking attributes about each type of pipeline, like, most importantly, stages. The challenge is linking the project record to a particular pipeline’s stages. You’d probably want to have a link directly from Projects to Stages since the stage value obviously needs to change over time (therefore a lookup won’t work). So at the end of the day, your project’s “stage” field is linking to “In-Progress” from Stages (for example). Now the problem is that you don’t have a single select containing a set of values that the pipeline element can display.
I’d recommend #2, or for database, app, and automation advantages, you could mix #3 with #2… so you’d have a link to Stages and that’s the main field driving the logic in the app, but then you could also have a single select in the project table that contains all possible stage values and is kept in sync with the project’s stage link, and used specifically for the pipeline element.
I have this exact same use-case for my projects. I agree that adding all the visibility filters is a cumbersome workaround. This would be great for Feature Requests
Since our data source is in Airtable here’s what I did (this is probably not relevant if you are using Noloco tables). I have my {project status} field linked to a project_status table (where each record is a status grouped by some high-level category). I then use an Airtable formula field to identify not only the linked status but some other logic as well (such as the deal status and project type) to determine the final status that should be displayed.
Airtable has the ability to output formula fields as a single-select (see screenshot). This allowed me to use the Noloco Stages element on a more sophisticated single-select field. That being said, I still needed to add some visibility filters so that only relevant statuses appeared based on the trajectory of that project’s path. (For example, “Cancelled” only appears in the element if the project is in that status, so it doesn’t appear in the stages element as some inevitable destination)
