TINDY_WORKS

STUDIO

SPACES

OFFICEGARDENRECEPTION

EDUCATION OPERATIONS // DATA INTEGRITY & SUPPORT WORKFLOWS

Student Intervention Automation

A configurable student-support automation built around a central Google Sheets tracker for organisations already working in Google Workspace. The workflow consolidates CRM, LMS, GitHub, and manually maintained support information into one operational hub, helping learning teams reduce repetitive data handling, review learner progress more consistently, and focus more time on meaningful support activity.

01 // Context

Learner-support information was distributed across CRM exports, LMS activity, GitHub signals, project deadlines, and staff-maintained notes. This created repetitive manual checking and made it difficult for learning teams to maintain a reliable operational view without moving between multiple systems. The challenge was to create a practical central hub within tools the organisation already used, while protecting manual context and maintaining reliable data-processing controls.

02 // The Approach

Designed a Google Workspace-native workflow around a central Google Sheets tracker, allowing operational teams to work from a familiar shared environment rather than introducing a separate platform. Google Apps Script retrieves and processes recent CRM reports, combines LMS and GitHub signals, preserves staff-owned notes, validates incoming information, and applies transparent risk rules around deadlines, resubmissions, and learner inactivity. The workflow is configurable for different programme structures and includes safeguards intended to reduce stale imports, duplicate processing, conflicting runs, unsafe overwrites, and schema drift.

03 // End-to-End Delivery

S.01

Google Workspace operational hub

A central Google Sheets-based tracker that brings together learner identifiers, CRM fields, activity signals, deadlines, risk reasons, and manually maintained support notes in a familiar shared workspace.

S.02

Multi-source data ingestion

Repeatable ingestion of recent CRM CSV reports alongside LMS and GitHub activity signals for a broader operational view.

S.03

Explainable risk evaluation

Transparent rules that flag deadline pressure, resubmission risk, and extended inactivity while keeping staff review and judgement central.

S.04

Data integrity safeguards

Validation, duplicate detection, file-age checks, schema checks, locking, controlled writes, and operational feedback to help protect tracker reliability.

S.05

Configurable operations design

Course presets and separated data ownership designed to support repeatable use across different programme structures and operational workflows.

FIG 1. SYSTEM ARCHITECTURE & DATA FLOW

DATA SOURCES

CRM CSV Reports

Recent learner and programme data

LMS Activity

Engagement, progress and activity signals

GitHub Activity

Optional profile and recent activity enrichment

Staff Notes

Manual context retained for support teams

PROCESSING & CONTROLS

AUTOMATION ENGINE

Google Apps Script

Configurable sync, validation, matching, risk evaluation and shared operational visibility

CENTRAL HUB

Google Sheets within the organisation's existing Google Workspace environment

File freshness checksDuplicate protectionSchema validationSafe writes & lockingManual-field preservation

OPERATIONAL OUTPUTS

Central Student Tracker

Joined-up learner progress and support view

Explainable Risk Flags

Deadline, resubmission and inactivity reasons

Sync Dashboard & Audit Log

Operational visibility and exception handling

Staff Review & Follow-up

Human-led intervention prioritisation

OPTIONAL

Optional AI-Assisted Preparation

Gemini for Google Workspace may support facilitator-led summaries and review preparation where enabled and approved

The workflow combines CRM, LMS, GitHub, and staff-maintained information in a controlled Google Apps Script process, then produces a central tracker, explainable risk indicators, operational audit information, and staff review inputs.

By keeping the operational hub within Google Workspace, the workflow helps teams spend less time locating, reconciling, and repeatedly checking learner information across separate sources. This leaves more capacity for facilitator-led review, timely communication, and meaningful learner support.

FIG 2. STUDENT INTERVENTION PROCESS

STEP 01 — CRM Report

A recent CRM CSV report is retrieved from the approved Gmail reporting workflow and checked before it is imported.

04 // Outcomes

01

Created a clearer operational view of learner information across multiple internal data sources.

02

Reduced repetitive manual checking by supporting repeatable CRM, LMS, GitHub, and deadline-processing workflows.

03

Provided staff with explainable risk indicators and preserved manual context to support more focused learner review and follow-up.

05 // Reliability, Safeguards & Configurability

P.01

DATA INTEGRITY

  • Freshness limits for incoming CRM files
  • Duplicate report detection
  • Required-field and header checks
  • Duplicate learner-record checks
  • Date validation and normalisation
P.02

SAFE PROCESSING

  • Runtime guard to reduce partial processing risk
  • Script locking to avoid concurrent sync conflicts
  • Suspiciously small data-set protection
  • Controlled write behaviour
  • Manual support notes preserved
P.03

CONFIGURABLE OPERATIONS

  • Course presets for different programme structures
  • Separated CRM, LMS, GitHub and manual field ownership
  • Optional activity-tracking features
  • Operational dashboard and audit surfaces
  • Designed for repeatable team workflows
P.04

WORKSPACE-NATIVE DELIVERY

  • Built around Google Sheets and Apps Script
  • Fits existing Google Workspace operations
  • Central shared hub for learner-support information
  • Supports shared Drive-based team working
  • Reduces the need for a separate operational platform

The workflow is designed to be configurable and repeatable across programme structures, while keeping data validation, staff context, and human review at the centre of the process.

OPTIONAL AI-ASSISTED REVIEW

Where an organisation has Gemini for Google Workspace enabled and approved for its data-handling requirements, the central tracker can provide a cleaner starting point for facilitator-led review, such as preparing summaries, identifying follow-up questions, or organising intervention discussions. Staff judgement, safeguarding processes, and organisational policy remain central.

06 // Integrity by Design

FIG 3. PRE-SYNC INTEGRITY GATE

INCOMING REPORT

CRM CSV REPORT

Recent scheduled report retrieved from Gmail

VALIDATION GATES

File freshness

Rejects reports older than the configured limit

Duplicate report check

Prevents the same CRM file being processed twice

Required-field validation

Checks expected learner identifiers and core CRM fields

Record consistency checks

Detects duplicate learner emails and record IDs

Schema compatibility

Normalises headers and flags unsafe mapping collisions

SAFE PATH

CONTROLLED UPDATE

Locking, safe-write behaviour, manual-field protection and suspicious-data safeguards

OUTPUT

CENTRAL TRACKER

Updated learner records, risk reasons, support notes and operational status

WHEN A VALIDATION CHECK FAILS — SECONDARY PATH

CHECK FAILED

One or more validation checks cannot be passed

STOP + SURFACE ISSUE

No tracker overwrite. Staff receive an operational error, alert, log entry, or review signal.

Before learner data is written to the central tracker, the workflow applies freshness, duplication, record-consistency, and schema checks. Where a check fails, the update is stopped and the issue can be surfaced for staff review rather than risking an unsafe overwrite.

FIG 4. DATA OWNERSHIP & MANUAL CONTEXT

HUB

CENTRAL STUDENT TRACKER

Joined operational view for staff-led support review

AUTO-UPDATED

CRM-OWNED FIELDS

Learner identity, programme and reporting data

Updated from approved CRM reports

AUTO-UPDATED

LMS-OWNED FIELDS

Recent activity, progress and lesson signals

Updated from learning-platform data

AUTO-UPDATED

GITHUB-OWNED FIELDS

Available GitHub profile and activity signals

Updated only where relevant data is available

STAFF-MAINTAINED

STAFF-OWNED FIELDS

Notes, risk context and manual support information

Preserved during automated updates

FIELD OWNERSHIP BOUNDARY

Automated syncs update only their designated data areas while manually maintained support context remains protected.

The tracker separates CRM, LMS, GitHub, and staff-maintained information so that automated updates can refresh their intended fields without overwriting the manual notes and support context that staff rely on during intervention work.

FIG 5. SAFE FAILURE & STAFF VISIBILITY

ENTRY POINT

SYNC ATTEMPT

SUCCESSFUL PATH

S.01

VALIDATED PROCESSING

Runtime guard, locking, controlled writes and risk evaluation

S.02

TRACKER UPDATED

Only approved and validated changes are applied

S.03

DASHBOARD / AUDIT VISIBILITY

Operational status, exceptions and sync context can be reviewed

STOPPED PATH

F.01

ISSUE DETECTED

  • Stale report
  • Duplicate report
  • Invalid or missing headers
  • Duplicate learner identifiers
  • Conflicting sync
  • Suspiciously small import

F.02

PROCESS STOPS SAFELY

No unsafe overwrite. The tracker remains protected while the issue is surfaced for review.

F.03

STAFF REVIEW / CORRECTION

Staff can correct the source issue, review operational feedback, and rerun the workflow when appropriate.

The workflow is designed to favour safe interruption over silent failure. When an incoming report or sync condition looks unreliable, processing can stop before unsafe changes are applied, leaving staff with a clearer route to investigate and correct the issue.