M
Malvika J.
Guest
If your team already pays for Microsoft 365, you have a ticketing system. You just have not turned it on yet.
Every brand team I have worked in or with has a very similar creative request process that requires someone to ping an in-house designer on Teams or forward an email that says, “Can we get this by Thursday?” Occasionally, that is followed up by another person on the thread adding a comment on the file, requiring the designer to keep a mental checklist of all of the asks, which sometimes ends up being too much. Then it is routed for approvals with more feedback, and the loop continues. Or it entirely lives in another system.
As someone who is not a developer by trade, and with feedback from my IT team, building a real ticketing system meant lots of time and cost for a full scope-out and full-blown project plan that met the business requirements, technical requirements, ensured adoption, was not cost-heavy, and addressed more internal requirements and processes.
Then I realized the tools were already available using the M365 subscription, and anyone, even non-technical folks, could build a working version in a matter of a few days.
The Flow
Why Power Automate
It made adoption easy because everything lived in the ecosystem everyone was already in day in and day out: Outlook, Teams, and the entire M365 suite. Power Automate let the intake stay within a Microsoft Form, which then led to an email notification that could easily be switched to a Teams message.
It came within a subscription that was already paid for, so cost wasn’t a factor. When you’re in a lean organization, “spending nothing extra” or “saving” is always a pro.
And finally, it kept all of the data safely housed within an environment everyone used, more specifically in a Microsoft List, which allowed filtering, reporting, and even Copilot layering.
The System That Was Built
Rather than building a custom solution with fields and needs that would make the requirements-gathering process go on, we built a simple Microsoft Form to collect the request. Using Power Automate, each submission became a new row in the Microsoft List and then emailed everyone who needed to know. With the org structure mapping in M365, it was also easier to bring visibility to managers and others.
The list then allowed the designer to work off a queue view, or have a project manager help prioritize, while also consolidating every comment and revision within the same list item until it was delivered.
There were a couple of moving parts: Form, List, Flow, Approvals. Email was the notification layer.
Code:
flowchart TD
A[Requester submits Microsoft Form] --> B[Power Automate trigger fires]
B --> C[Create item in Microsoft Lists<br/>Status = New]
C --> D[Email alerts<br/>requester receipt + creative inbox]
D --> E[Designer works the queue view<br/>sets In Progress]
E --> F[Comments and revisions<br/>tracked on the list item]
F -->|Revisions Requested| E
F --> G[Approved and Delivered]The next few sections will outline each of the steps in greater detail.
Part 1: The Intake Form
It requires opening Microsoft Forms, creating a new custom form, and naming it the “Creative Request Form.” Given the flexibility of the system, it first started with a few simple inputs:
| Field | Type | Why it is a dropdown or required |
|---|---|---|
| Brand or platform/channel | Dropdown, required | Spelling stays consistent so you can filter later |
| Request type | Dropdown, required | Product image, video edit, ad creative, social post, packaging, other |
| Description | Long text, required | Hint text: “What, for whom, and what good looks like” |
| Reference links | Text | Briefs, folders, examples |
| Needed by | Date, required | Drives the queue sort and the reminders |
| Specifications | Text | |
| Priority | Dropdown | Standard or rush |
We prioritized dropdowns as much as possible since free text can create a number of variables. This would streamline the input and briefing so the designer could always expect the same thing, which in turn improves productivity.
Also, turning on the setting that records the responder’s name allows email notifications to flow through easily and ensures that everyone is signed in, so it is limited to organizational data and users only, creating a natural security layer.
Part 2: The List
This eventually works as the database and houses all of the tickets and requests. It is also where all of the comments, adjustments, revisions, and everything else live.
It just requires going either to your team’s SharePoint site or directly to the Microsoft Lists app and creating a new list. This then has a column for each of the form questions, matching the input types:
- Choice columns for dropdowns
- Date for deadlines
- Multiple lines of text for descriptions, links, and specifications
It should also include additional columns that come after a request has been submitted, such as:
| Column | Type | Purpose |
|---|---|---|
| Status | Choice | New, In Progress, Ready for Review, Revisions Requested, Approved, Rejected |
| Assigned To | Person | Which designer owns it |
| Requester | Person | Filled by the flow from the form response |
| Feedback | Multiple lines of text, append changes on | Running log of every round of comments |
| Round | Number, default 1 | How many revision cycles the ticket has been through |
| Final Deliverable Link | Hyperlink | Where the finished work lives |
| Approval Comments | Multiple lines of text | What the approver said |
Set the default Status to New.
These are some of the additional settings that help turn this into a tracking system:
- Turn on versioning so that every field change is stored with who made it and when.
- On the Feedback column, turn on “Append Changes to Existing Text” so that instead of overwriting, it builds on the previously submitted comments for history tracking.
- Use the built-in comment panel for anything back and forth, which allows tagging, no different from comments in a Word document, so it is all visible for everyone to see instead of getting lost in emails.
To make it easier to navigate, we also built three views:
- Designer Queue: Filtered to Status is New, In Progress, or Revisions Requested, sorted by Needed By ascending. This is the only screen the designer truly needs to reference.
- My Requests: Filtered so the Requester is [Me].
- All Open Requests: Grouped by Status so that it is easy for whoever is managing the designers.
This also eliminates the Teams ping of, “What’s the status of my work?” because everything is transparent and visible.
Part 3: The Flow After the Input
Now that the two key components, the input and the tracking of all inputs, are in place, the next step is to build a flow.
Go to Power Automate, choose Automated cloud flow, and pick the trigger “When a new response is submitted” from Microsoft Forms. Select your form.
Then add these actions in order, using the names below so you can easily follow along and build:
- Get response details (Microsoft Forms). This is the step people miss. The trigger only tells you a response exists. This action pulls the actual answers. Select the same form and use the Response ID from the trigger.
- Create item (SharePoint). Pick your site and list. Map each form answer to its column. For Requester, use the Responder’s Email from the response details. Set Status to New and Round to 1.
- Send an email (Outlook) to the requester. Subject: “Creative request #[ID] received: [Brand] | [Type] | due [Needed By].” Body: a one-line confirmation and the link to their list item. Power Automate gives you “Link to item” as a field automatically.
- Send an email (Outlook) to the creative team inbox with a standard subject-line naming convention, plus the description and reference links in the body so the designer can triage from Outlook directly.
Save it. Test it by submitting a form yourself, and if something breaks, the run history shows you exactly which step failed and what it received, in a way that is more readable than most error logs I have seen.
Part 4: The Tracking Flow
Once the intake flow runs, which happens once per request, the tracking follows whenever someone changes the ticket, makes a comment, or adjusts the list item.
This requires a second automated flow with a trigger: “When an item is created or modified” (SharePoint), pointed at your list. Add a Switch action on the Status column with one case per status:
| Status changes to | Who changed it | What the flow does |
|---|---|---|
| In Progress | Designer | Emails the requester: picked up by [Assigned To], due [Needed By] |
| Ready for Review | Designer | Emails the requester with the Deliverable Link and one line: approve or add feedback on the ticket |
| Revisions Requested | Requester | Increments Round by 1, emails the designer with the latest Feedback entry and the item link |
| Approved | Requester or approver | Emails both parties, closes the item |
| Rejected | Approver | Emails the requester with Approval Comments |
This also allows the process to be tracked much more closely and makes it possible to understand how many revisions there are, improve briefing, and add more fields or inputs over time so the process becomes more streamlined.
There is one guard you should add: the flow that updates the item will also trigger itself again. To avoid an infinite loop, add a condition so that the flow only runs when Status actually changes, or check at the top that the modified-by user is not the flow’s own account.
Part 5: The Approval Loop
Since most requests will need some sign-off before the designer marks them as complete, especially from someone in marketing if the work is facing someone externally, a simple branch can be added to the intake flow after the item is created.
For example, if Priority is rush or Request Type is ad creative, run an approval first.
The action is “Start and wait for an approval.” Choose Approve/Reject - First to Respond and assign it to the approver based on the designer’s manager or someone in the brand team.
In the details, this can include the description and reference links so the approver can decide without opening anything else. The approval shows up in their Outlook and Teams with Approve and Reject buttons. They click one.
That is the entire approver experience.
If the approver does not respond within one week, you can set a timeout to escalate to their manager or let a daily reminder run until a certain window.
Part 6: The Project Management
To also avoid creating multiple emails for everyone, a simple scheduled flow can run every week or every other day, extracting from the list all of the items where Status is not Approved or Rejected and Needed By is within two days.
For each one, it sends a consolidated email to the creative inbox listing what is due, with a link to each item.
The Major Win
Before the system, everyone sent in their request in a different shape and format. Now, it follows a standardized format and also boosts productivity.
It also allows the use of a very underutilized tool, especially for non-technical people to build systems that make their lives easier and that are not always the top priority among the larger projects taking up the technology team’s time.
The AI Angle
Especially now that everyone is trying to adopt AI, a standardized system and process like this allows structured input to be fed into a single data source and then allows some useful questions to be asked:
- Which platform has the most rush requests?
- What is our average turnaround by request type?
- Which requests end up needing more than two rounds of feedback?
- What is the most common feedback?
And now with Power Automate, there is the added benefit of Copilot, which allows you to describe the flow and helps help generate or modify flows from natural-language descriptions.