Status Controller Page

Status Controller – Page and Relationships
 

Full Functional Description
 

1. What the Status Controller Page Is (Conceptually)
 

The Status Controller page is a matrix-style dashboard designed to give teams a single-screen overview of customer progress, stages, or states across multiple dimensions.
 

Think of it as:
 

Customers on the left × Status columns on the right, changing over time


Each row represents one customer, and each column represents one tracked concept (stage, status, step, approval, KPI, etc.).

Each cell answers a simple question:
 

“What is the status of this customer for this column in this month?”


2. Overall Page Structure (What the User Sees First)
 

When a user opens the Status Controller, the page feels like a dashboard, not a form.
 

At the top:
 

  • A clear title showing Status Controller and the currently selected month and year

  • A help icon for guidance

  • Date controls to move backward or forward in time
     

Below that:
 

  • Search input to quickly locate customers

  • A settings shortcut (gear icon) for admins

  • The main table occupying most of the screen
     

The design is intentionally wide and scrollable because:
 

  • Status tracking is horizontal by nature

  • Multiple columns must remain visible at once
     

3. Date Logic (Time-Based Behavior)
 

Time is a core dimension of the Status Controller.
 

By default:
 

  • The page loads with the previous month

  • This prevents accidental changes to the current month

  • It encourages reflective or reporting-style usage
     

Users can:
 

  • Change the month

  • Change the year
     

The moment either value changes:
 

  • The table reloads

  • All data shown now belongs to that month

  • The structure stays the same, only the values change
     

This makes the page function like:
 

  • A monthly snapshot

  • A historical tracker

  • A comparison tool across time
     

4. Search and Filtering Behavior
 

The search field filters customers only.
 

When a user types:
 

  • The system does not change columns

  • It does not affect status definitions

  • It simply narrows the visible customer rows
     

This is important because:
 

  • Structure remains stable

  • Focus stays on tracking, not restructuring
     

5. Table Layout – How the Grid Is Built
 

The table has two fixed columns on the left and multiple dynamic columns on the right.
 

Fixed columns
 

The first column always shows:
 

  • Customer identity

  • Usually name, avatar, or identifier

  • Sometimes includes selection checkboxes
     

The second column always shows:
 

  • Responsible team members

  • Derived from customer ownership or sharing

  • Displayed visually using avatars or initials
     

These columns never change position.
 

6. Dynamic Columns (The Heart of the System)
 

All columns after “Responsible” are dynamic.
 

They are:
 

  • Defined entirely in settings

  • Loaded from the system configuration

  • Rendered only if they have names
     

Each column:
 

  • Has a unique meaning

  • Represents a tracked dimension

  • Has its own set of allowed statuses
     

The system supports up to 10 columns, but users only see what is configured.
 

7. Cell Behavior (How Users Interact)
 

Every cell represents:
 

One customer + one column + one month


If no status exists:
 

  • The cell shows a placeholder

  • Typically “Select status”
     

When the user clicks the cell:
 

  • A dropdown opens

  • The dropdown lists all allowed statuses for that column
     

Each status:
 

  • Has a label

  • Has a color

  • May require additional input
     

8. Date and Value Capture (Advanced Interaction)
 

Some statuses are simple:
 

  • Click → applied → done
     

Other statuses are enhanced:
 

  • They require a date or numeric value
     

In those cases:
 

  • Selecting the status opens a small input modal

  • The user enters the required data

  • On submit, the status is saved together with that data
     

This allows the grid to capture:
 

  • Completion dates

  • Scores

  • Amounts

  • Quantitative progress
     

9. Loading Strategy (Performance by Design)
 

The Status Controller is designed for large datasets.
 

Instead of loading everything at once:
 

  • The system loads customers in batches

  • Initial load is fast

  • More rows can be loaded on demand
     

Users can:
 

  • Load more rows incrementally

  • Or load all rows at once if needed
     

This keeps the UI:
 

  • Responsive

  • Stable

  • Usable even with thousands of customers
     

10. Column Width and User Preferences
 

Each user can resize columns.
 

When a column is resized:
 

  • The new width is saved for that user

  • Next time they open the page, widths are restored
     

This personalization ensures:
 

  • Power users can optimize their view

  • Different roles can focus on different columns
     

11. Core Data Relationships (How Everything Connects)
 

Behind the scenes, the page is driven by four main entities working together.
 

Organization → Status configuration
 

Each organization has one Status configuration.
 

That configuration defines:
 

  • Which customers appear (via folder rules)

  • Which columns exist

  • What statuses are allowed

  • Which columns are static or time-based
     

This configuration is the blueprint of the page.
 

Customers (contacts)
 

Customers are:
 

  • Filtered by folder rules

  • Loaded only if they belong to allowed folders

  • Displayed one per row
     

Their responsibility data determines:
 

  • Who appears in the Responsible column
     

Monthly status records
 

For every customer and every month:
 

  • There is a dedicated status record

  • That record stores values for all columns
     

This design allows:
 

  • Historical tracking

  • Month-by-month comparisons

  • Safe editing without overwriting past data
     

Users (team members)
 

Users appear in two roles:
 

  • As responsible owners of customers

  • As configuration owners and permission holders
     

They also store:
 

  • Column width preferences

  • Module access permissions
     


12. How the Page and Settings Work Together
 

The Status Controller page is read–write, but not self-defining.
 

Users can:
 

  • Select statuses

  • Change values

  • Navigate months
     

But they cannot:
 

  • Create new columns

  • Add statuses

  • Change logic
     

All structural changes happen in Status Controller Settings.
 

This separation ensures:
 

  • Stability

  • Predictable reporting

  • Controlled customization
     


13. Mental Model for Users
 

For end users, the Status Controller feels like:
 

  • A living spreadsheet

  • A monthly tracker

  • A visual control panel
     

For admins, it is:
 

  • A configurable workflow engine

  • A reporting foundation

  • A flexible CRM layer
     


14. Summary
 

The Status Controller page is where configured business logic becomes visible, editable, and trackable.
 

It:
 

  • Displays customers filtered by rules

  • Shows progress across custom dimensions

  • Changes over time by month

  • Stores data safely and historically

  • Scales to large datasets
     

All relationships exist to support one goal:
 

Clear, fast, structured insight into customer state — at scale.
 

information_img

מוצרים

מודולים

מאפיינים

מחירון

עלינו

צרו קשר

עוד

BIZ1 CRM
באינטרנט
איש קשר Biz1.co.il