What belongs here
Use this category to request new platform capabilities or major workflow improvements. Describing the underlying problem, alongside the interface you have in mind, gives product teams the room to design something that works across very different campus environments.
An effective request covers four things:
- The operational problem. What is difficult, slow, risky, or impossible today.
- The affected roles. Who runs into it, and how often.
- Institutional constraints. Governance, privacy, accessibility, LMS, and procurement realities that shape any solution.
- The desired outcome. What success looks like once the problem is gone.
Search for duplicates first
Search the category using feature terms, workflow names, and user roles before you create a topic. Adding to an open topic keeps one need in one place, which makes the whole case easier to read.
- A matching request already exists. Like the topic and reply with your institutional details.
- The closest topic is broader or narrower than your need. Reply with your specific context, so the difference between the general request and your situation is on the record.
The required request format
Opening a topic in Ideas pre-fills your composer with the template below. Product feedback that is not a specific request can clear the sections that do not apply.
## The problem
[Describe what task is difficult, slow, risky, or impossible today in plain language]
## Who has it
[Example roles: faculty teaching large introductory courses, instructional designers, campus IT administrators managing multiple workspaces, campus office staff such as admissions or advising, students using approved public agents, or library staff. State how many people are affected and how often]
## Current workaround
[Describe the manual process, another tool, or why the work is not completed, and the cost in time, errors, training, support load, or inconsistent outcomes]
## What success looks like
[Describe the outcome rather than only the proposed interface, how you would know it worked, and acceptance examples in the form "A workspace administrator can ...", "An instructor can ...", "A student can ...", "A campus IT team can ..."]
## Institutional context
[Course size or teaching model, governance or privacy requirements, accessibility requirements, LMS environment, integration constraints, procurement or support constraints, and whether it affects one department or the whole institution. Do not include credentials, student data, or private URLs]
## Proposed approach, if you have one
[Optional: share ideas while keeping focus on the problem and desired outcome]
## Related topics
[Link to related forum topics or requests]
What makes a request easy to evaluate
- A clear problem statement. Operational context tells us far more than a UI mockup on its own.
- Scale. How many users or departments hit the issue shows how widely the need generalizes across the community.
- Measurable outcomes. Stating what success looks like lets engineering design something that fits multiple higher education environments.
A request does not need to be long to be worth posting. The problem, who has it, and what a good outcome would look like are enough to work from. Start here: Ideas covers the rest of how this category works.
Before you post
Before sharing prompts, configurations, or screenshots, review Community sharing and responsible AI use. Never post student records, personally identifiable information, or credentials.