Skip to content

Status

SLID

Old Notes to Update

Status Level ID (SLID)

Comprised of 3 components using floating numeric field type of 3 decimal places.

Status Level

ID Structure
slid description
99 Starting level 10-99
999 Mid level 100-999
9999 Base level 1000-9999

Status Level Attributes

Owner
sla_own description example
00 Any Any user has access.
01 Group Only group member have access.
02 User After owner complete change to group.
Ready
sla_ready description example
00 Ready Record becomes part of normal system.
01 Progress In progress becoming ready.
02 New After saving change to incomplete/complete.
Write
sla_rw description example
00 Write Changes can be made.
01 Readonly No changes can be made.
02 Write Once After saving change to readonly.
Life
sla_life description example
00 Permanent
01 Temporary After 30 days change to hidden or purge.
02 Hidden/Purge After 90 days purge.

Sales Scenario

This scenario assumes 1000 is a sales lead that turns into a 1100 which is a client. The stages show the work flow from loading a new lead to archiving the client that is no longer being served.

The format is SLID-SA where SA represents all (3) Status Attributes together as one number.

New Leads

  • New leads imported (slid=20) from a file to be checked before made available for assignment to sales team.
  • Permissions (sla_own=1,sla_ready=1) is owner (not available to sales team until verified import successful.
    • If import batch has errors, delete and reimport.
    • If records are ready change (sla_read=0) use button option that automatically updates imported batch to new leads ready (slid=100,sla_ready=1,sla_own=0,sla_life=0). The leads are temporary and any leads that are not updated within 60 days will automatically revert back to unassigned (slid=100).
  • Sales team manager assigns leads (slid=1000,sla_own=1) to people on the sales team. Each lead can only be seen or updated by the sales person or administrator. The sla_ready remains 1 because it is a new lead to the sales person.
  • The sales person updates the lead (sla_ready=0). The temporary status (sla_lif) of the lead is changed to permanent (sla_life=null).
  • Multiple follow-ups are made until the lead is ready (sla_readyy=null) for an appointment (slid=1070).

History

Recording changed to history is critical to any system. The method used is understood by the following examples.

Lead to Client

The lead (1000) becomes a client when the sale (1090) is made. When the slid changes from 1000 to 1090, an unconfirmed (10901) record is created in history containing additional information from the file. Upon confirmation the all information is correct, the unconfirmed (10901) record becomes confirmed (109011) and the history data cannot be changed.

While the record remains in the 1090 status, any referencing of the record will cause the system to look for the (109011,10901) and return the first match. If 109011 is returned, the record is readonly unless the status changes. If 10901 is returned, the record can be updated and confirmed.

If the status changes while the history record is unconfirmed, the unconfirmed record remains in history and a new history record is created, also unconfirmed.

Unconfirmed history records are just previously entered information. The most recent changes while in that status. The are not counted as history in reports and are not visible on embedded tables.

Confirmed history records all have 11 following the status code.

Mechanisms
  • Status Menu
    • Simple way to change status without buttons or questions.
    • Limited to allowable status codes based on current status and/or user rights.
    • Usually set in a Mode screen with related fields to the status.
  • Change of Status (onchange event)
    • By changing the status and reloading the form, the system attempts to link that status to history.
    • History records use the same status code followed by 1’s. A status code 1000 may have:
      • 10001 (unconfirmed, updating information)
      • 100011 (confirmed, used as current information)
      • 1000111 (archived information)
    • The sytem always pulls the lowest number first when on a mode form for that status code. Other forms will only link to 100011 records. Archive records will only apear in embedded history tables.

Status Level Activity Timeline (SLAT)

The status codes in an SLAT table are:

slid command comments
99991 resume User must complete record
9999 history Last record reflects current status

New records are added using the ~~newrecord=unbound switch parameter.

Example:

        $this->form2 = $this->createForm($this->form2q, $keys, [
            'slat'   => [
                'bind'    => $this->form1->key,
                'dbk'     => 'key',
                'resume'  => true,
                'history' => true
            ],
            'insert' => [
                'dbt'      => $key->dbt,
                'map'     => [
                    'acct2'    => branch()->pro->swacct,
                    'entry'    => ['NOW'],
                    'updated'  => ['NOW'],
                    'expires'  => ['NOW', 30],
                    'initials' => user_initials(),
                    'reg_id'      => vnix::$user->id
                ],
            ],
        ]);
bind

The keys to bind the activity timeline to.

dbk

The field name in history that links to the bind form key

change (experimental)

The field that if it changes should trigger a new history record. Default is the main form slid (dbs).

resume = true

If exists, open the SLID1 record.

Do not create a new record if exists or does not exist.

resume = false

Do no load previous SLID1 record if exists.

history = true

Load history if it exists. Does not affect creating records.

history = false

Do not load history records. Does not affect creating records.