Automation  ·  IT and security

How to automate request intake forms

A request arrives in Slack, a second copy arrives by email, and neither says which cost centre it is for. Here is how intake that captures a request once, complete, actually works, the prompts that build it, and what running it demands.

Built with Tray Headless

  1. System Typeform
  2. Step Identify the requester
  3. Step Prefill from systems
  4. Step Check it is complete
  5. System ServiceNow
Also Ask for what is missing

One entry point per kind of request, the form fills what the systems already know, and nothing reaches an owner until it is complete.

The short answer

What is request intake automation?

Request intake automation gives each kind of request one entry point, fills in what the company's systems already know about the requester, checks the request is complete before anyone sees it, and creates one tracked record with an owner and a due date. Most intake fails on the back-and-forth. A request that reaches its owner without the cost centre, the system or the business reason sits until somebody chases the requester, and the chasing takes longer than the work.

Stage 1 of 7: Request and intake. Part of Process automation, end to end : every stage, the systems it runs on and the guide that builds it.

What matters here

  • Give each kind of request one entry point. Five ways in means five partial copies of the same request.
  • Fill in what the systems already know. A requester should never type their manager, department or cost centre.
  • Check a request is complete before an owner sees it. An incomplete request is the most expensive kind to receive.
  • Ask only the questions this request type needs. A form that asks everything gets answered with guesses.
  • Create one record with an owner and a due date, and tell the requester where it is.
  • Measure how often requests come back for more information. That number tells you which question is missing.

Who this is for

You run business systems or IT operations. Requests reach your teams through Slack, email, a shared form and hallway conversations, and half of them need a follow-up before anyone can act.

How it works in practice

What has to happen between somebody asking for something and an owner being able to act on it.

  1. 1

    The request comes in through one door

    A form, a Slack shortcut or a Teams message, all feeding the same intake for that request type.

  2. 2

    The requester is identified

    Matched to their record in the HR system or directory, so their manager and department come with them.

  3. 3

    Known fields are filled in

    Cost centre, location, current access, the account they work on, read from the systems that hold them.

  4. 4

    The request is checked for completeness

    Against the rules for that request type, before anyone is asked to look at it.

  5. 5

    Anything missing goes back to the requester

    One specific question, in the channel they asked from, not a reply-all thread.

  6. 6

    One record is created with an owner

    In the system the owning team works in, with a due date the requester can see.

What intake is made of

Four pieces, and the second is the one that removes most of the chasing.

One entry point per request type

A purchase request, an access request and a contract review each get their own short form. Several channels can feed it, but they all land in the same place.

Prefill from systems of record

Anything a system already knows is filled in and shown to the requester, not asked for. People mistype cost centres; directories rarely do.

A completeness check per type

Rules held as data: which fields each type needs, which values are allowed, and what makes a request ready for its owner.

One record, one owner, one status

Created in the system the owning team already works in, and visible to the requester without them having to ask.

The Tray Headless prompts

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

  1. 1

    Set up one entry point per request type

    Five ways in means five partial copies of the same request.

    Headless skills build-workflow 

    Use build-workflow. The systems in play are Typeform, Slack, ServiceNow
and Workday, or whatever we run in those seats.

List the request types we handle today and give each one an entry
point: a short form, plus a Slack shortcut that opens the same form.
Requests sent by email to the team inbox should be turned into the same
record with a note asking the requester to use the form next time.

Each request type gets its own form. One long form with a "type"
dropdown at the top produces requests where half the answers belong to
a different type.

Record which channel each request came from, so we can see which doors
people actually use.
  2. 2

    Identify the requester and fill in what is known

    A requester should never type their manager or cost centre.

    Headless skills build-workflow tray-patterns 

    Use build-workflow. When a request arrives, match the requester to
their Workday record by email address or Slack user, and read their
manager, department, cost centre and location.

Add anything else the request type needs that a system already holds:
the apps they already have access to from Okta, the account they work
on from Salesforce, the open requests they already have in ServiceNow.

Show the filled-in values to the requester and let them correct a
value, but never ask them to type one a system already knows. If the
requester cannot be matched, say so and route the request to a person
rather than creating a record with blank ownership.

    Check for an open request of the same type from the same person before creating a new one. Duplicate requests are the most common reason two people work the same thing.

  3. 3

    Check the request is complete before an owner sees it

    An incomplete request is the most expensive kind to receive.

    Hold the rules for each request type as data, not as conditions in the
workflow: which fields are required, which values are allowed, and any
limit that changes who has to approve it.

Check each request against its rules. If something is missing or out
of range, send the requester one specific question in the channel they
used, and keep the request in a waiting state until they answer.

Never pass a request to its owner with a field blank and a note saying
"please confirm". That is the back-and-forth this step exists to
remove.
  4. 4

    Create one record with an owner and a due date

    So the request is tracked in the place the owning team already works.

    Headless skills tray-gotchas 

    Use tray-gotchas, then create the record in ServiceNow (or Jira, for
teams that work there) with the request type, the requester, every
field, the owning team and a due date set by the request type.

Post the record link back to the requester with the due date. Update
them when the status changes, so they never need to ask where it is.

If creating the record fails, keep the request and retry. Never tell the
requester it was logged until the record exists.
  5. 5

    Report on the back-and-forth

    Which question is missing is in the data.

    Write each request to Snowflake with its type, channel, the fields that
were prefilled, the fields that failed the completeness check and how
long the request waited for the requester.

Report by request type: how often requests go back for more
information, which field causes it, and how long the wait adds. A field
that fails often is a question the form is missing or a value a system
should be filling.
  6. 6

    Validate it, then hand the forms to the owning teams

    Because request types change more often than the workflow should.

    Run the per-step checks and the whole-workflow audit before this goes
live. Test each request type with a complete request, one missing a
required field, one from a requester who cannot be matched, and a
duplicate.

Then open the same workflow in Tray Build so each owning team can
change its own questions, required fields and due dates in the visual
canvas without a deployment.

What it connects to

Requests come in through the channels people already use, and leave as one complete record in the system the owning team works in.

Typeform

Hold the short form for each request type.

Reads

Slack

Open the form from a shortcut, ask the requester for anything missing, and post status updates.

Reads and writes

Workday

Identify the requester and supply their manager, department, cost centre and location.

Reads

Okta

Show which apps the requester already has, so an access request starts from what is true.

Reads

ServiceNow

Receive one complete record per request, with an owner and a due date.

Writes

Snowflake

Hold every request with its completeness failures, which is where the missing questions show up.

Writes

Same build, other stacks

The design does not change if you run something else in one of these seats. The same prompts build it against Google BigQuery, Microsoft Teams, Azure Active Directory, SAP SuccessFactors, Jira or Databricks.

Connections in this build

Field mapping, templates and common problems for each pairing: Typeform + Slack, Workday REST + Slack, Okta + Slack and Okta + Workday REST.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Running it in production

Intake is where every process starts, so it has to be up when people ask.

It runs on the platform, not on your laptop

Requests arrive at any hour and the requester expects an answer in the channel they asked from, not the next morning.

The rules live outside the workflow

Required fields and allowed values per request type, held as data, so a team changes its form without anyone editing logic.

Credentials are managed, never in code

Read access to the HR system and directory, and write access only to the system where records are created.

Every request is kept

Including the ones that never became a record, so a request that disappeared can be found and explained.

Teams own their own forms

Open in Tray Build, so the people who receive a request type decide what it asks.

Questions people ask

Why one form per request type?

Because a single long form answers questions for every type at once, and the answers that belong to a different type are guesses. Short forms per type are answered properly.

Why prefill from other systems?

Because a requester typing their own cost centre or manager is the most common source of a wrong value, and the HR system already knows both.

Can requests still come in by Slack or email?

Yes. Each channel feeds the same intake for its request type, so a Slack shortcut and a form produce the same record.

How is this different from IT service desk fulfilment?

That guide covers what happens after an IT request is logged, through to it being done. This is the front door any team's requests come through, IT or not.

Which metric matters most?

How often requests go back to the requester for more information, by request type and by field. It points at the exact question the form is missing.

Related guides

Finance

How to automate approval routing

Hold who approves what as data, send each approver the facts they need where they work, set a deadline that escalates, and keep the record. The prompts.

IT and security

How to build IT service desk fulfilment

Catalogue the requests worth automating, fulfil the safe ones end to end, and route the rest with everything already gathered. The prompts that build it.

IT and security

How to build access request and approval

Route to the system owner, grant with an expiry by default, provision automatically, and produce the access review as a by-product. The prompts that build it.

Last reviewed October 2026.