Earlier this year, we started talking about a new initiative at GraceRock: the building of GraceBlocks. We’re on deck this week to discuss pillar #7: Tracking, and this week, we’re going to get straight to it.
The word tracking can mean a lot of things. In the end, it comes down to what it is that is being tracked: people, places, widgets, projects all have information about them and their relationships that need to be tracked. For example, take applicant tracking. For this, you need to track candidates and their expression of interest (an application) in one or more jobs, and the steps the applicant travels through as they are being considered for that position. The candidates can have various touch-points as they consider and apply to jobs, you’ll likely want to track those. The jobs applied for have locations, job functions, descriptions, and various other pieces of information such as who the recruiter or manager is, as well as the salary grade. I could go on and on. Any system of record has data, great, so what?
In our case, when we reference the pillar of tracking, we are not talking about the primary system that is being designed and what it tracks. We’re talking about tracking OF the tracking. The who, what and when of every piece of data that is supplied into the system or edited by the system. It’s great to know that someone applied to a job. Most systems will track the date an application is added and the dates of the key movements in the hiring life-cycle. But the real work comes in tracking all of the metadata, who touched what and when? If the location of the job changed, what was it before, and who changed it? If a letter used to extend an offer was updated, who changed it and when? What text changed?
Most systems do a good job of tracking their primary data of record and their basic movements – when was it first put into the system? when was it last updated? But all of the ancillary activity that fully audits what’s happening in the system across every piece of data, this usually falls into the cracks, especially when it comes to administrative data sets that support the system.
This GraceBlocks pillar is an acknowledgment of the fundamental need for tracking all changes (who’s doing them, what was the data prior/post-change, and when) to ensure easy auditing of the information stored inside any Block built with GraceBlocks.
Want to stay informed?
Be sure to sign up for updates. And we’ll keep you posted as we continue building GraceBlocks!
Read about the other pillars here:
- 10 Pillar’s summary post
- Pillar #1: Security
- Pillar #2: Ease
- Pillar #3: Search
- Pillar #4: Collaboration
- Pillar #5: Integration
- Pillar #6: Control