Building an Intake for Internal Requests with Microsoft Forms — Consolidating Email and Verbal Requests into a Form

“Please create a server account” arrives by email; “the printer is playing up, can you look at it” is asked in passing in the corridor; “please process this invoice” is a sticky note on your desk. We hear from departments that receive internal requests — IT, general affairs, accounting — that they want to do something about this state of affairs.

The person making the request assumes that saying it means it will get done, and the person receiving it has nothing to go on but their memory and their mailbox. On the busiest day one request goes missing, and it comes to light with “what happened with that thing I asked about?” For a company that has already deployed Microsoft 365, this problem can largely be solved with an “intake pattern” that uses Microsoft Forms as the front door and Power Automate to automate notification and record-keeping. This article covers the practicalities of form design, the constraints on file uploads, the basic shape of the intake flow, and the limits of Forms on its own that make transcription into a list the standard approach. Designing the approval and authorization itself is the subject of the separate article “Building an Approval Workflow in Power Automate — Digitizing Paper and Email-Based Approval Requests,” so this one sticks to the “intake.”

1. The Bottom Line First

• Design a request intake as an “input pattern” and a “place to keep the record” together. The realistic minimum configuration is “receive it in Forms → transcribe it into a SharePoint list with Power Automate → notify.”
• The basic shape of the flow is two steps: the trigger “When a new response is submitted” and the action “Get response details.” The Forms connector has only this one trigger and one action (plus getting form details), so there is not much to learn.¹²
• As a rule, the audience should be organization-only. Enable “record name” and the respondent’s name and email address are recorded automatically, removing the need to make people write their name and department. With a setting that also opens the form outside the organization, responses are anonymous and there is no record of who submitted them.³
• File upload questions are exclusive to organization-only forms. A single question takes up to 10 files, the per-file limit is chosen from 10 MB, 100 MB, or 1 GB, and files are stored in OneDrive for Business.⁴
• The trick to longevity is to treat Forms strictly as the intake. It has no features for editing after submission or checking progress, and the response list has no state management, so the ledger lives on the SharePoint list side.⁵
• The response ceiling on work and school accounts is up to 5,000,000, effectively unlimited for internal use, but above 50,000 the summary charts and viewing individual responses become unavailable. The “weak list management” bites long before the ceiling does.⁶
• Intake from outside the company with attachments, high volumes needing integration with core systems, exposing progress to the requester — around here you start to exceed what Forms is built for. The dividing lines are summarized in the decision table in Section 7.

2. What’s Actually Wrong With Email and Verbal Requests

The problems with running an intake on email and verbal requests lie in structure, in a place no amount of effort by the person handling them can fix.

• Things fall through the cracks structurally. Because requests arrive by separate routes — inbox, chat, spoken word, sticky note — “the list of everything” exists nowhere. You are betting on one individual’s memory to not drop a single item.
• Formats vary, so exchanges multiply. An email that says only “please set up a PC” leaves the machine in question, the desired date, and the reason unknown, and a round of clarification follows. Having to remember and write out the necessary details for every request is a burden on the requester too.
• State is invisible, and it turns into “I told you” / “you didn’t”. From the requester’s side, there is no way to see whether the request has been accepted, whether work has started, or when it will be done. If the person handling it says “I never heard about it,” it is one word against another. The chasing and confirming exchanges themselves eat into both sides’ time.
• You cannot aggregate. Because no data remains on how many requests arrive per month and what time is being spent on what, you cannot back up claims like “we’re short-staffed” or “this system generates too many queries” with numbers.

All of these move toward resolution together once you have a mechanism that makes the entry point for requests singular, receives the necessary details in a fixed pattern, and leaves a record and a notification the moment a request is received. The reason to use Forms and Power Automate is that, if Microsoft 365 is already deployed, this mechanism can usually be built within the scope of no additional cost (the Forms, SharePoint, Outlook, and Teams connectors used in this article are all in the standard connector range. How to think about licensing is set out in “Power Automate Licensing and the Boundary Between Standard and Premium Connectors”).

3. The Practicalities of Form Design

Make “Choosing” the Default for Questions

The goal of form design is that the requester can submit without hesitation and the receiver has the information needed to act without asking follow-up questions. The principle is “receive it as choices, keep text to a minimum.”

• Make the request type a choice question. Something like “Account creation / PC and peripherals / Software installation / Other” — settle the axis you will later use for aggregation and for branching in the flow as a set of choices.
• Receive deadlines as a date question. This removes the ambiguity of “ASAP” and “sometime this week,” and makes the value usable for reminders on the flow side (business days and cut-off dates are covered in “Designing Scheduled Flows in Power Automate — Month-End Processing, Business-Day Checks, and Reminders in Practice”).
• Consolidate free text into a single “additional notes” question as a rule of thumb. One practical caution here: there is a known issue where a flow works intermittently if a single line of text question (short answer) receives input longer than 255 characters. Any question that might receive a long answer should be a “long answer” (multiple lines of text) from the start.⁷

And do not make people write too much. The role of an intake form is to capture requests without losing any, not to extract every piece of information on the spot. A form with too many questions drives people back to the corridor and the inbox. For matters that need a detailed conversation, work on the basis that the assignee will follow up after intake, and keep the form to a granularity that takes a couple of minutes to submit.

Use Branching So People Don’t See Irrelevant Questions

When different request types call for different questions, use branching. Because you can switch which question or section is shown next depending on the answer to a choice question, you can show respondents only the relevant questions — “for account creation, the target system and the permissions; for equipment failure, the asset number and the symptoms.” Branching can only jump forward to a later question (you cannot go back to an earlier one), so the easiest structure to build is common questions at the front and type-specific questions split into sections at the back.⁸

Audience and Respondent Information — Organization-Only vs Anonymous

There are three audience options in Forms.³

As a rule, an internal request intake should be organization-only. There are three reasons.

1. You avoid making people write down “who submitted this.” Enable “record name” and the respondent’s name and email address are attached to the response automatically. You can delete the “write the same thing every time” questions — name, department, contact details — entirely.³
2. Some features, such as one response per person and file uploads, are only available with an organization-only audience. “One response per person” can also only be configured when the audience is organization-only.³
3. The flow can reply to the requester. Because the response details include the respondent’s email address (Responders’ Email), you can send an acknowledgement email straight away (Section 5). An anonymous form cannot do this.⁹

Note that whether respondent names are recorded by default across the whole organization is something an administrator can control in the Forms settings of the Microsoft 365 admin center (“record names by default”). Whether the tenant permits external sharing (soliciting responses from outside the organization) at all is a setting on the same screen. If your company has a policy such as “internal surveys are anonymous by default,” check here as well.¹⁰

Don’t Leave It as a Personal Form — Prepare for the Author Leaving

This gets overlooked but matters. A form created by an individual is tied to that person’s account, and if the account is deleted from the tenant — because they leave, for example — the account-related data disappears 30 days after deletion.¹¹ Because an intake form is the front door to a business process, do not let it be one person’s property: create it as a group (team) form, or establish a practice of transferring ownership when people transfer or leave.⁷

There is one caution on the flow side. Group forms do not appear in the list of form IDs in the Power Automate trigger, so you have to copy the value after FormId= from the URL of the form’s edit screen and enter it manually as the form ID.² It is a minor nuisance, but avoiding single-person dependency is worth more.

4. File Upload Specifications and Constraints

There are plenty of cases where a request comes with an attachment: “a purchase request with the quotation PDF attached,” “a fault report with a screenshot of the error.” You need an accurate grasp of how Forms’ file upload questions work.⁴

• They are exclusive to organization-only forms. They can only be added when the audience is “only people in my organization can respond” or “specific people in my organization can respond,” and cannot be used on a form opened to people outside the organization. In other words, you cannot use Forms for “have an external trading partner submit a request with an attachment.”
• A single question accepts up to 10 files, and the per-file size limit is chosen from 10 MB, 100 MB, or 1 GB.
• You can restrict file types. You can choose which of Word, Excel, PowerPoint, PDF, image, video, and audio to permit, so you can receive things like “quotations as PDF only.”
• The storage location depends on who owns the form. For a personal form, uploaded files accumulate in the author’s OneDrive for Business under “Apps > Microsoft Forms > (form name) > (question name)”; for the group form recommended in Section 3, they accumulate on the group’s SharePoint site.

Handling uploaded files from a flow takes a little extra work. The answer to an upload question returned by “Get response details” is a JSON string containing file names and IDs, so you give it a schema with “Parse JSON” to break it apart, extract the file ID with an expression such as first(body('Parse_JSON'))?['id'], and pass that to the file retrieval action. The schema can be generated automatically by pasting the output of a test run as a sample.⁹ Note that first(...) is written on the assumption of a single file. For a question that permits multiple files, the answer comes back as an array of one object per file, so loop over the parsed result with Apply to each and retrieve one file at a time (if one attachment is enough for the request, the simplest option is to set the question’s own limit to a single file). Also, match the connector you use to retrieve the file to the storage location above. For a personal form, the OneDrive for Business connector; for a group form, since the storage location is the group’s SharePoint site, use the SharePoint connector and point it at that site. Looking for the files of a group form with the OneDrive connector and not finding them is a classic mismatch and a classic stumbling block.

If you want to attach a received file to an approval request, pass the file content as binary to the attachment field.¹² Note, however, that the approval action can attach files up to 5 MB to the email; beyond that, the approver has to check them in the approvals list in the Power Automate portal.⁷ For large files, storing them in SharePoint and circulating a link is more reliable than passing them around as attachments.

5. Running the Intake with Power Automate

The Basic Shape: Two Steps and Three Exits

Forms does not tell anyone when a response arrives, at least by default (there is a notification setting for the form owner, but you cannot choose the recipient or the wording⁹). Running the intake as a business process is Power Automate’s job. The basic shape of the flow is two steps: specify the form in the trigger “When a new response is submitted,” then use “Get response details” to expose each question’s answer as dynamic content.¹ From there, the three exits are “record it in the ledger,” “acknowledge to the requester,” and “notify the handling team.”

flowchart TD
    Submit[Requester submits via Forms<br/>Organization-only, signed in] --> Trigger[When a new response is submitted<br/>Cloud flow starts]
    Trigger --> Details[Get response details<br/>Answers become dynamic content]
    Details --> Record[Create item in SharePoint list<br/>Status: Received]
    Record --> Ack[Acknowledgement email to the requester<br/>Insert a copy of the answers]
    Record --> Team[Post to the handling team's Teams channel]
    Record --> Need{Request type needing approval?}
    Need -- Yes --> Approval[Into the approval flow<br/>Start and wait for an approval]
    Need -- No --> Work[Assign an owner and handle it]
    Approval --> Back[Write the result back to the list]
    Work --> Back2[Update progress in the status column]

Transcribing to a SharePoint List — Building the Intake Ledger

Received requests are transcribed one row at a time into a SharePoint list at the start of the flow. The key point is to give the list, in addition to a copy of the answers, the “columns for management” that the form does not have.

Keep follow-up questions to the requester and the running narrative in this list (or in a Teams thread tied to the list item) rather than scattering them across email, and the record that settles “I told you” / “you didn’t” ends up in one place. Create a view filtered to “status = incomplete” and you have a work list you can use as-is in the morning stand-up. There are templates for transcribing to Excel as well,⁹ but for a ledger whose state several people keep updating, a list — with its views, column types, and version history — is the better fit. How to think about migrating from an Excel ledger to a list is set out in “Replacing an Excel Ledger with a SharePoint List — Flow Integration That Makes the Ledger Move.”

Acknowledgement — Reply “We’ve Got It” Within the First Minute

This is where the difference from email requests is felt most. Send two kinds of notification from the flow.

• An acknowledgement email to the requester. With an organization-only form, you can send it straight to the respondent’s email address (Responders’ Email) included in the response details, using the Outlook connector.⁹ Put a copy of what they submitted in the body, plus an expectation such as “someone will be in touch within three business days.” Most of what makes requesters want to chase is simply not knowing whether the request even arrived, so this one email cuts queries considerably. Forms itself also has a setting for a confirmation email to the respondent, but sending from the flow is what lets you tailor the wording to the business.⁹
• A Teams notification to the handling team. Sending to an individual’s email brings back single-person dependency, so post to the handling team’s channel. Include the type, deadline, and requester along with a link to the list item, and the channel becomes an “inbox for new requests” in its own right.

Connecting to Approval

For types such as “software purchases need line-manager approval,” connect the intake flow to an approval action (Start and wait for an approval). There are templates that insert the Forms answers into the approval request, and you can build the whole thing through to sending the requester a result email based on the approval outcome.⁹ Design questions such as the type of approval, timeouts and chasers, and how to preserve the approval record are covered in detail in “Building an Approval Workflow in Power Automate — Digitizing Paper and Email-Based Approval Requests,” so refer to that. Once the intake flow is running stably, put co-owner settings and error notifications in place early too (for error handling design, see “Power Automate Error Handling and Retry Design — Preventing ‘The Flow Was Working, Then It Just Stopped’”).

6. The Limits of Forms on Its Own — Why Transcribing to a List Is the Standard

Try to complete the intake with Forms alone and you hit the following walls.

• State after submission is invisible. By default, respondents cannot amend what they submitted afterwards. In some environments a setting has rolled out that lets the author allow respondents to save and edit their own responses, but that only amounts to a means of correcting the answers. What the form offers as settings is things like the start and end date for accepting responses and the one-response-per-person limit,⁵ and there is no screen where a person can check the current state of their own request (received, in progress, complete) — it fits reality better to assume there are no features supporting “after submission” at all. In environments where editing is not permitted, corrections get made by “submitting again,” and it falls to the receiving side to work out which one is current.
• The response list has weak management features. The Forms responses screen is for aggregation and viewing; it cannot hold a status column or an assignee, and it cannot “show only the outstanding ones.” What intake management needs is the ability to “keep updating” a list, and that is outside what Forms is built for.
• The ceilings bite on features rather than volume. A form on a work or school account can receive up to 5,000,000 responses per form, with 200 questions and 4,000 characters per text answer (there is also a limit of 200,000 characters of text answers per response, but that is a ceiling one respondent reaches within a single submission, not something you reach as responses accumulate). What bites first in practice is not the volume but the feature restrictions: above 50,000 responses, summary charts, viewing individual responses, and printing become unavailable, leaving only CSV export.⁶ You are very unlikely to hit the volume ceiling with an internal intake, but for a long-running form the design of “accumulating everything in Forms” starts to tell. The guidance is that once responses build up you export and then clear them,¹¹ so either way you need a separate place to keep the history.

In short, Forms is excellent as “a tool for distributing an input pattern,” but it is not “a tool for managing what happens after intake.” The division of labor — Forms as the intake, SharePoint lists for the ledger and state management, Power Automate for notification and integration — is the standard approach precisely because it plays to each one’s strengths.

7. How Far to Take Forms — A Decision Table

There is a progression of tooling for an intake. Here is a rough guide.

The instinct for the judgement is: “you can keep pushing Forms for as long as the requesters are inside the company; once outsiders are involved, change the design.” Rethinking the intake for paper, FAX, and email attachments exchanged with external parties is covered in “Moving FAX Orders to the Web ── Designing the Dual-Operation Period and a Phased Migration” and “Automating Purchase-Order and Invoice PDFs That Arrive by Email With Power Automate — Designing Storage, Routing, Notification, and Extraction.”

8. Summary

What makes email and verbal requests painful is that the full set of requests exists nowhere, the formats do not line up, and the state is invisible. Make the entry point singular with Microsoft Forms, automate “who submitted this” with an organization-only audience and name recording, and use Power Automate to return a ledger record and an acknowledgement the moment a request arrives. This pattern alone makes a great deal of the “what happened with that thing I asked about?” traffic disappear.

The design points are: a form built around choices that does not make people write too much; understanding the difference between organization-only and anonymous; grasping the file upload constraints (organization-only, up to 10 files, up to 1 GB per file); and not expecting Forms to be a ledger. Forms is the intake, the list is the ledger, the flow does notification and integration. An intake that keeps to this division of labor keeps running for a long time, even as the people staffing it change. And when intake from outside the company, attachments, volume, and integration requirements start to swell, that is the moment to start considering web form development or a dedicated system.

Related Articles

• Building an Approval Workflow in Power Automate — Digitizing Paper and Email-Based Approval Requests
• Replacing an Excel Ledger with a SharePoint List — Flow Integration That Makes the Ledger Move
• Automating Business Processes with Power Automate — Cloud Flows, Desktop Flows, and Robust Error Handling
• Automating Purchase-Order and Invoice PDFs That Arrive by Email With Power Automate — Designing Storage, Routing, Notification, and Extraction

Related Consulting Areas

KomuraSoft LLC handles everything from consultations on building intake, ledger, and notification mechanisms for internal processes using Microsoft 365, through to developing the external-facing web forms and business systems that Forms cannot contain.

• Technical Consulting & Design Review
• Windows App Development
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Frequently Asked Questions

Common questions about the topic of this article.

Can people outside the company use file upload questions in Microsoft Forms?

No. A file upload question can only be added when the form's audience is set to "only people in my organization can respond" (or specific people in the organization); with a setting that also allows responses from outside the organization, the question type itself becomes unavailable. Uploaded files are stored in the organization's OneDrive for Business, and a single question can accept up to 10 files, each up to a limit you choose from 10 MB, 100 MB, or 1 GB. If you need to receive attachments from outside the company, either use OneDrive/SharePoint's file request feature alongside it, or consider building a web form.

How many responses can a Microsoft Forms form receive?

A form on a work or school account can receive up to 5,000,000 responses (50,000 in GCC High/DoD environments). You are very unlikely to run into that ceiling with an internal request intake, but above 50,000 responses features such as the summary charts and viewing individual responses become unavailable, leaving only CSV export. And because the response list has no state management, the standard approach regardless of volume is to transcribe received requests into a SharePoint list with Power Automate and manage them there as a ledger.

Can the identity of the respondent be recorded automatically?

Yes, if you restrict the audience to your organization. Set it to "only people in my organization can respond" and enable "record name," and the respondent's name and email address are recorded automatically along with the response, so there is no need to make people type their name and department. The option to limit people to one response each is also only available with an organization-only audience. Conversely, with "anyone can respond" the responses are anonymous and there is no record of who submitted them. As a rule, an internal request intake should be organization-only.

Should the intake be built with Forms or with a SharePoint list?

Forms if you prioritize ease of input for the person filling it in; a SharePoint list if you prioritize ledger management. Forms is easy to fill in from a phone and makes branching and required fields simple, but it has weaknesses on the intake-management side: respondents cannot edit after submitting or check progress, and the response list has weak management features. In practice, a configuration where "Forms receives it and Power Automate transcribes it into a SharePoint list" gets you both ease of input and ledger management. For a standardized request with many fields, where everyone submitting it can work with a list, receiving directly through the list's own form is also an option.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.