πŸ’‘Kanban Requirements Assistant

Let's Design Your Flexi Kanban Board

We're here to help you scope out the requirements for the new Kanban board for our Customer Success team. We will walk through four key areas to create a clear specification for the PoC.

Step 1: The Data Source (Salesforce Object)

QUESTION 1: What is the API Name of the primary Salesforce object your team wants to visualize on this Kanban board?

First, we need to know where the data is coming from. The Kanban board will display records from a single primary object in Salesforce. We need the API Name of this object, which is how the system identifies it.

  • What is an API Name? It's the unique, unchangeable name for an object. Standard objects have simple names (like Case, Account, Opportunity), while custom objects usually end with __c (like Onboarding_Project__c or Success_Plan__c).

  • Common Examples for a Customer Success Team:

    • Case (for support or success tickets)

    • Account (for managing a portfolio of customers)

    • Opportunity (if the CSM team manages renewals or upsells)

    • Task (for tracking specific actions)

    • A custom object like QBR_Meeting__c or Customer_Health_Check__c.

Step 2: Card Information (Fields)

QUESTION 2: Please list the fields from the [Insert the Object Name from Step 1 here] object that should be displayed on each Kanban card.

Next, let's decide what information needs to be visible on each card at a glance. This helps your team quickly understand the context of each item without having to click into the record.

Think about the most critical pieces of information your team needs to see.

  • Examples:

    • For a Case object: Case Number, Subject, Priority, Customer Name, Case Owner.

    • For an Account object: Account Name, Health Score, Renewal Date, CSM Owner, ARR.

Step 3: Color-Coding Rules

QUESTION 3: What are the color-coding rules you want to implement for your Kanban cards?

Color is a powerful tool for drawing attention to what matters most. We can set up rules to change the color of a card or a specific part of it based on field values. Please describe the rules you'd like to apply.

You can format your rules like this: IF [Field Name] [Condition] [Value], THEN color the [Card Element] [Color].

  • Card Elements: You can color the entire card, a header bar, a side border, or a specific tag.

  • Examples:

    • IF Priority equals High, THEN color the entire card light red.

    • IF SLA_Status__c equals At Risk, THEN color the side border orange.

    • IF Health_Score__c is less than 60, THEN color the header bar yellow.

Step 4: Workflow, Stages, and Movement Rules

QUESTION 4a: Defining Kanban Columns and Mapping to Salesforce Data

Now, let's define the core of your Kanban board: the workflow stages and how records move through them. This involves defining the columns on your board and how they map to data in Salesforce.

i. Column Names: What are the visual columns (or stages) you want on your Kanban board? Please list them in the order they should appear from left to right.

Example: Backlog, To Do, In Progress, Awaiting Feedback, Completed.

ii. Stage-Defining Field: Which field on the [We will insert the Object Name from Step 1 here] object determines the stage of a record? The values in this field will be used to place records into the correct columns. Please provide the Field API Name.

This is often a picklist field like Status, StageName, Phase__c, etc.

iii. Value-to-Column Mapping: How do the specific values of the field [Insert the Field API Name from 4a.ii here] map to the columns you listed in 4a.i? For each column, please specify which field value(s) should cause a record to appear in that column.

Example:

  • Backlog column: Status__c = 'New'

  • To Do column: Status__c = 'Assigned' OR Status__c = 'Open'

  • In Progress column: Status__c = 'Work in Progress'

  • Awaiting Feedback column: Status__c = 'Pending Customer Response'

  • Completed column: Status__c = 'Resolved' OR Status__c = 'Closed'

QUESTION 4b: How should users be able to move cards between these columns?

When a user drags a card from one column to another, this typically updates the "Stage-Defining Field" (identified in 4a.ii) on the Salesforce record to the corresponding value for the new column. Now, let's define the rules for how users can move cards between these columns.

Consider the following:

  • Unrestricted: Can cards be moved freely between any columns, forward and backward? (e.g., moving a card from In Progress to To Do is allowed).

  • Forward-Only: Can cards only progress to subsequent stages? (e.g., a card in In Progress can't go back to To Do but can go to Awaiting Feedback or Completed).

  • Specific Restrictions: Are there conditions that must be met before a card can be moved into or out of certain columns? Or actions that should happen after a move?

    • Example 1 (Pre-condition): "A card cannot be moved to the Completed column unless the Resolution_Details__c field is filled out."

    • Example 2 (Restriction): "Only the record owner or a manager can move a card from the To Do column to In Progress."

    • Example 3 (Locking): "Cards in the Completed column are locked and cannot be moved back to any previous stage."

    • Example 4 (Automation/Post-action): "When a card moves to 'In Progress', the 'Actual_Start_Date__c' field should be automatically populated with today's date."

Please describe the rules for moving cards on your board, including any field updates (beyond the stage field) that should occur automatically when a card is moved to a new column, or any conditions that prevent movement.

Once you provide the answers to these four steps, we will compile them into a final requirements document that can be handed off to build the Proof of Concept.

Last updated