Campus operations where every student request reaches the office that can resolve it — and the student can see where it is

Mi Retail is an operations center for educational institutions. It does not replace the student information system or the learning platform; it manages the administrative work that crosses offices around them. A certificate request, a grade correction, an enrollment change, a transfer credit review or a facilities incident becomes an Operational Work Item with an owner, a state, a due date and evidence. Each person sees what is theirs: student services sees incoming requests, the registrar sees records to verify, faculty see grades to confirm, the dean sees sign-offs and campus leadership sees only what is stuck. The academic record itself stays in your SIS or in the Education edition apps of StoneOS.

No. Your student information system stays the system of record for enrollment, grades, programs and academic history, and your learning platform keeps courses, assignments and content. Mi Retail does not duplicate either. It covers the work those systems leave to email and walk-ins: a grade that a professor has not posted, a signature the dean has not given, a hold that another office has to clear, a document that must be delivered. Each work item can reference the record in the SIS, so staff go to the SIS for academic detail and to Mi Retail to know who has to act next, what is blocking it and by when.

The student requests the certificate through the portal, and it arrives in student services as a work item with a due date. The registrar opens a review to verify credits, final grades and graduation requirements in the SIS; if a grade is missing, a child work item goes to the professor. If student accounts has an administrative hold on the student, that work item is blocked with the reason, so everyone knows what is missing. Once the record is verified and the hold is cleared, the dean signs off from the same work item. The registrar issues the certificate, student services delivers it, and the request closes with each step recorded.

Yes. When a student files a request, it appears in their My Requests view with its current state, who is working on it and the expected date, without exposing the internal conversations of each office. If the request is blocked — for example, because of an account hold — the student sees that it is blocked and what they need to do to move it forward. When the document is issued and delivered, the student is notified and the evidence of delivery stays attached. That alone removes a large share of the calls and emails that service desks receive, because the question “where is my certificate?” already has an answer.

The hold stops being a surprise at the last window. As soon as the registrar sees that student accounts has an administrative hold, a work item is created for student accounts and the certificate request is marked blocked with that reason. The student sees what is pending, student accounts sees the case in its own queue with a due date, and the dean does not receive a sign-off request for a document that cannot be issued yet. When student accounts confirms the hold is cleared in its finance system, the blocked work item is released and the registrar is notified to continue. Nobody has to rediscover the problem or restart the request.

Each role gets its own surface over the same operation. Student services staff and registrar clerks start from Today and My Work, with the requests they have to move. Office coordinators use Team Operations to see what is unassigned, blocked or about to miss its date. Professors and deans see only the work items that need them — a grade to confirm, a sign-off to give — without learning a new system. The provost or campus director uses Operational Portfolio to compare offices and faculties, and Executive Operations for exceptions that need a decision. Control & Assurance lets internal audit or a quality team review how documents were issued.

Yes, as long as both organizations are on Mi Retail. A transfer credit review that needs a syllabus from another university, a degree verification requested by an employer or a joint program with a partner institution can move as derived work items. The requesting institution picks the other organization from the directory and sends the request; it lands in that organization’s own intake queue, where their registrar assigns it internally. Each side keeps its privacy: the requester follows the state, the due date and the result, but not the other institution’s internal work. When the answer comes back, it is attached as evidence and the original work item continues.

Any process where something needs a person to act and cross an office. Common ones are admissions exceptions that need a committee decision, grade corrections that need the professor and the registrar, enrollment changes after deadlines, scholarship or fee reviews, schedule conflicts between programs and facilities incidents such as a broken projector before an exam. Each becomes a work item with an owner, a state and a due date, and escalates to a coordinator or a dean when it gets stuck. Institutions usually start with academic documents because they are frequent and visible to students, then extend the same way of working to the rest of the campus.

Every work item keeps who acted, when, in which state and with which attachments. For an academic certificate, that means the original request, the record verification, the grade the professor posted, the hold that was cleared, the dean’s approval with its date, the signed document with its verification number and the delivery receipt. When a student disputes a delay, an employer questions a document or an internal quality review asks how certificates are issued, the institution can show the full sequence instead of rebuilding it from inboxes and paper files. Because the evidence is captured while the work happens, it holds up when someone checks it later.

Yes, it is the same product at both ends. In a small school where the same few people handle admissions, records and student services, the experience reduces to one Today view with the requests waiting, blocked or due this week, without empty teams or invented hierarchies. In a university with several campuses, faculties and thousands of students, the same work items are distributed across student services, registrars, faculties, student accounts and campus leadership, each with its own surface, and exceptions escalate to the level that can decide. What changes is how responsibilities are split between offices and campuses, not the way the work is represented.

The Education edition of StoneOS brings apps for the domain work of an institution — Admissions, Enrollment, Programs, Cohorts, Schedules, Student Records, Student Services, Tuition & Fees, Academic Documents, Credentials, Certifications and Campus Operations — on top of the Business Core apps every team uses: Chat, Docs, Drive, Calendar, People, Notes, Sheets, Slides and To-do. Those apps keep the depth of each domain. Mi Retail is where the work they generate meets the people who must move it: a document request, an enrollment exception or a hold lands as a work item in the right office’s queue. If you prefer to keep your current SIS, it stays the record.

Start with one request type that students complain about — certificates, transcripts or enrollment changes — instead of modeling the whole institution. Create the workspace for student services and the registrar, invite the professors and deans who sign, add student accounts for holds, and let the first requests arrive as work items with an owner and a due date. Within a few weeks you will see where requests wait, which offices carry the load and how often holds appear late. Then add the next request type or the next campus. Mi Retail is free to start, so one office can prove the approach before the rest of the institution joins.