Digital Learning Tracker for Paid Apps

What this resource is

Resource #3A brings several connected digital learning responsibilities into one planning document. Its application inventory records instructional purpose, ownership, sign-on and rostering arrangements, integration considerations, semester tasks, and school coverage. Its contract records connect licenses and expiration information with the people responsible for instructional and fiscal follow-through.

The workbook helps a team answer practical questions: Which schools use an application? Who owns the setup work? What changes at the semester transition? Which contracts need attention? Which staff roles need access?

Inside the seven tabs

The four Harry Potter house names represent individual schools in this sample. Replace Hufflepuff, Gryffindor, Ravenclaw, and Slytherin with district school names; “Hogwarts” is the sample district heading.

1. Digital Learning Systems Master. The first tab is the alphabetic application overview. It includes subject/content, owner or data champion, single sign-on (SSO), student roster source, Schoology integration, S1/S2 tasks, and school indicators. Semester notes flag items such as rollover, syncing, and new-teacher setup.
2. Active App Contracts Master. The second tab records teacher, student, and school licenses; invoice number; expiration month/day and year; contract verification; champion/owner; and fiscal liaison. Additional columns capture overview, audience, impact, resources, and teacher notes. Sections distinguish districtwide and school-based apps, apps under consideration, and a sample unsupported-app list.
3. Hufflepuff. A school-specific view of application and contract details for the first sample school.
4. Gryffindor. The same contract-oriented structure for the second sample school.
5. Ravenclaw. The same structure for the third sample school.
6. Slytherin. The same structure for the fourth sample school. Use all four school views alongside the districtwide contract section so shared services remain visible.
7. Roles for App Access. A job-title matrix maps expected access across HR, directory, student information, and learning systems. Department headings identify responsibilities across HR, IT, SIS, and digital learning (DL); entries include Yes, No, Admin, Teacher, and unresolved question marks.

How the digital learning team could use it

1. Prepare for the school year. Confirm the application list and school coverage with site leaders. Review each owner, sign-on method, roster source, and integration. Turn the brief semester notes into assigned setup tasks with a due date and a completion check in the district’s task system or an added tracking field.
2. Check readiness before instruction begins. Coordinate with IT and SIS staff to verify the intended classes, users, and access paths. Record open issues and the person responsible for follow-up. A populated inventory row alone does not confirm successful setup.
3. Review each semester transition. Use the S1/S2 column to identify rollover, roster updates, course changes, and new-teacher setup. Confirm completion with the application owner and affected schools.
4. Plan renewals ahead of expiration. Review upcoming contracts with the fiscal liaison and instructional owner. Confirm license quantities, school needs, the renewal decision, and supporting documentation. Add a locally appropriate decision deadline that accounts for purchasing lead time and any notice requirements in the contract.
5. Coordinate staffing changes. Use the role matrix during onboarding, transfers, and departures to identify which teams must review access. Resolve question marks and verify actual permissions in each system.
6. Close the year and preserve continuity. Reconcile school coverage and contracts, document unresolved issues and renewal decisions, and retain a dated copy before preparing the next year’s working version.

Who contributes what

Adapt the draft before operational use

The sample provides a useful coordination structure. The following refinements would make a district working copy more dependable; they are suggested improvements, not features already established in the draft.

• Refresh sample information. Replace school and staff names, verify products and contacts, and update the “Contract Verified 25–26?” heading and example dates for the active planning cycle. The unsupported-app section reflects the sample’s labels, not an SDLA approval or prohibition list.
• Define status meanings. Establish how to use Yes, New, No, blank, and dash indicators. The first tab counts both “YES” and “NEW” in its school total, so that total should not be presented as confirmed active use without checking each status.
• Separate contract milestones. The sample verification heading refers to an invoice being submitted to Finance. Track renewal approval, invoice submission, payment, and service activation separately when the team needs to distinguish those steps.
• Make renewal follow-up actionable. Consider adding full expiration dates, renewal decision dates, costs, funding source, document links, next action, and last-reviewed date. The current contract sheet does not provide a complete cost or budget model.
• Establish one authoritative record. Use consistent application names and a stable application/contract identifier. Confirm how the school views will stay aligned with the master before maintaining parallel copies.
• Validate access expectations. Agree on role definitions and department handoffs. Use the matrix to guide review; verify each actual access change in the relevant system.

Source reviewed: _Sample_ Digital Learning Tracker for Paid Apps.xlsx, all seven tabs. This page describes the supplied draft and suggests a local workflow. The workbook has not been revised, and live refresh behavior has not been verified.