Ask your LMS and SIS data in plain English — get SQL back

The questions are ordinary. How is enrollment trending this term? Which courses do people start and not finish? Which accounts are behind on a required activity?

The answers usually sit in two places: the learning system and the student information system. The joins are real. The boundary between institutions is real. And the only people who can write the query are usually on the engineering team.

So a product manager, a success lead, or an ops manager writes a ticket. Someone context-switches, writes SQL, pastes a result, and the next version of the question starts the loop again.

That is a workflow problem. A chat box that invents a number does not fix it. A BI project that takes two quarters might, eventually. A smaller version is enough to start: the person asks in the words they already use, and the system returns the answer plus the SQL it actually ran.

Questions worth answering first

Start with questions your team already asks every week. If a question needs a new definition of "active" before anyone can agree on it, it is not a first question.

• How does enrollment this term compare with the same point last term?
• Which courses have a high start rate and a low completion rate?
• Which institutions are behind on a required activity or form?
• What does one learner's record look like across the LMS and the SIS, for a support case?

These are cross-system questions. A chart inside one product rarely has both sides.

What "SQL back" should mean

The person asking should not have to know table names. They should still be able to trust the answer.

• Map only the LMS and SIS tables the question is allowed to touch.
• Turn the question into SQL.
• Check that SQL before anything runs: allowed tables, an institution filter, no writes.
• Show the answer in sentences, and keep the query available for someone who wants to see it.

The SQL is the receipt. If a number looks wrong, an engineer can read the query instead of reverse-engineering a chat transcript.

What has to be true before you turn it on

• Institution boundaries are explicit. A question about one school cannot wander into another.
• The schema map is smaller than the warehouse. If the assistant can see every table, it will eventually use one you did not mean.
• Validation sits in front of execution. A model that can run whatever it wrote is a query console with extra steps.
• The first release covers a short list of questions. Everything else gets a clear "I can't answer that yet," not a guess.

A first version that is allowed to be narrow

You do not need every report the company has ever wanted. Pick the queue of questions that currently interrupt engineers, write down the tables those questions use, and ship a conversation that only answers that set.

I built this shape for an enterprise edtech platform: plain-English questions over a multi-tenant LMS and SIS, with the SQL checked before it ran. The writeup covers the constraint, the checks, and what changed for the people who used to file the tickets.