0

Using the Kanban View to show only certian parts of the workflow

I'm not sure if this is a good idea to use it in this way or I am doing something wrong.

I have a dropdown list on a form for the status of jobs, the options are Pending, On Hold In Progress, Dead, Complete and Invoice Me. I use this field to populate the Kanban Column Headers.

I would like to restrict the amount of column Headeres in the Kanban, so I don't have to see the Dead and Invoice Me options as these will clog up the lists and make it difficult to know what work is still live.

I appreciate I could be doing this all wrong and maybe there is a better way to do this.

Any ideas most welcome.

As a side note, why do some dropdown lists have an empty option and some don't, I can't see what triggers this?

7 replies

null
    • Mconneen
    • 4 yrs ago
    • Reported - view

    @DavidW.... that is an interesting use case.. Kanbans form vertical swimlanes based on the values..  

    First.. You seem "empty".. when the field that the kanban is based on is "required = no".. If you want to avoid the "empty".. make the field required .. with a default value. 

    Now.. stripping off the Dead and "Invoice Me" status.. Hmm..  Interesting.. So.. if you create a filtered table view removing those status.. you STILL see the column.. Makes sense.. as the Kanban is based off the FIELD definition, not the table view.. SOOOO .. hmm... I would have to play with it a lot more... I have a few ideas. but it doubtful they will pan out.. :( 

    • Mconneen
    • 4 yrs ago
    • Reported - view

    OK.. a quick test.. and YES.. Lets assume you have a Status field (all the values you reference above).. and a "View Status" field . that drops the two status you do not want to see.  Put logic in the "Trigger After Update".. and if it is the value you WANT to see. copy it over. if it is one you do NOT want to see. Do not copy it over.. NOW.. here is where a little back door helps.. Declare the "View Status" field as "Required".. but Ninox will still permit it to be null... In most cases.. something bad.. in this case. SWEET.. 

    Next.. create table view for all status ... and one for the View Status .. then create Kanban views off those source views.. POOF.. 

    Thoughts?? 

    kanbanAllStatus

    kanbanViewStatus

    • Mconneen
    • 4 yrs ago
    • Reported - view

    CRAP.. Sorry.. Here is the "View Status" kanban view. 

    kanbanViewStatus

    • Monions
    • 4 yrs ago
    • Reported - view

    Has a better solution been found to this issue?

    I have exactly the same problem as David, the original poster. I want to only see the 'swimlanes' that I have applied a filter for. I like the Kanban view, it is an idea way to view a workflow progress, but not if it is cluttered with the lanes that are not required.

    This solution of creating a specific to replicate the 'status' field in order to just view what is needed is inefficient and very clunky. I am surprised fewer people have requested a fix for this issue?

    • Mconneen
    • 4 yrs ago
    • Reported - view

    Monions... The concept of the "workflow" and kanban is that the field that you are declaring the kanban view over represents each step.  Why have superfluous steps if you do not want to see them? 

    • Monions
    • 4 yrs ago
    • Reported - view

    Thanks for your reply. I wished to use the Kanban view as a nice way to visualise the status of an opportunity. There are a number of status levels - some of which I'm not interested in seeing in the Kanban view as they are not needed on a day to day level. Things like 'Dead' and 'Active' are not needed in an opportunity pipeline as they have either died or been won and converted to an active position. Once they are active, they are not an opportunity and are handled by another workflow.

    It appears that I wish to use a Kanban 'view' where as there appears to be a general philosophy on what Kanban is and that is not what I need. I will just use a filtered list as this works exactly how I would expect it to work - just not as visually appealing.

    • Mconneen
    • 4 yrs ago
    • Reported - view

    The after update trigger approach above is rather clean.  Yes.. You have to define a "shadow field"  and table view first..   Lets assume the pipeline status has 9 potential values. 

    pipeline

    Create a REQUIRED TEXT filed.. "Active Satus".. Then put the following logic in the Status trigger after update. 

    trigger

Content aside

  • 4 yrs agoLast active
  • 7Replies
  • 3066Views