Chapter 10 — Reference codes and lookups
Lesson map
Lesson 10 published. Map, example, EX028.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Code lists"]
N2["10.2 Consistency"]
N3["10.3 Changes over time"]
N4["10.4 Documentation"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX028"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Code lists"]
N2["10.2 Consistency"]
N3["10.3 Changes over time"]
N4["10.4 Documentation"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX028"]
[Learning outcomes]
|
v
[10.1 Code lists]
|
v
[10.2 Consistency]
|
v
[10.3 Changes over time]
|
v
[10.4 Documentation]
|
v
[Worked example] --> [Exercise EX028]
Learning outcomes
You will (1) manage reference code lists; (2) keep lookups consistent across systems; (3) handle code changes over time.
10.1 Code lists
Calder Valley uses many code lists: priorities, job types, property types, contractor identifiers and complaint categories. Ravi finds job type lists differ between the housing system and the contractor portal, with some codes in one but not the other. He creates a master list in a reference table, owned by the repairs steward, and a mapping table linking portal codes to master codes. Unmapped codes are flagged when files load. The steward approves the master list and the mapping after checking each code with the call centre and contractors.
10.2 Consistency
Ravi writes a nightly check comparing code lists in each system with the master list. Differences appear in a short report to the steward. When a new job type is needed, the steward adds it to the master list first, then IT and the portal team add it to their systems. He notes that this order prevents systems drifting apart, which had caused reports to drop jobs with codes not recognised by the reporting tool. The report is usually empty, which shows the process works.
10.3 Changes over time
Codes change. Calder Valley merges two job types, plaster repair and wall repair, into one. Ravi adds start and end dates to the master list, so historical reports still show the old types for past periods while new jobs use the merged code. He creates a mapping for trend reports that need consistent categories across time. He explains that deleting old codes would break historical reports. The steward approves the end dates and the mapping, and Ravi tests the trend reports to confirm that past periods still show the expected categories.
10.4 Documentation
Each code has a description, examples and the date it became valid. Ravi publishes the master list on the intranet so call handlers can check meanings. A call handler notices that two codes have nearly identical descriptions and asks which to use. The steward clarifies the difference and updates descriptions. Ms. Moreau notes that publishing code lists invites useful questions, which improves consistency more than keeping lists hidden in system tables. Call handlers now consult the published list regularly, and the number of jobs recorded under the wrong type falls.
Worked example
Ravi creates a master job type list with portal mappings, runs nightly consistency checks, adds start and end dates for a merged code and publishes descriptions that prompt a useful clarification.
Synthetic case. Code lists are synthetic.
Errors and limits
Deleting old codes breaks historical reports; end-date them.
Exercises
- EX028 — Master list owner. Who owns the master job type list? Rubric: 3 = the repairs steward;; 2 = partly correct;; 1 = other;; 0 = none.
- EX029 — Change order. What order is followed for new job types? Rubric: 3 = master list first, then systems;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX030 — Merged types. Which job types were merged? Rubric: 3 = plaster repair and wall repair;; 2 = both;; 1 = one;; 0 = none.
Continue studying — lesson 10 (chapter 10 of 30)
← Chapter 09 · Course chapter index · Chapter 11 →
Continue to the next authored lesson.