Describe your systems and approval rules. Makeform turns them into a new user account request form for employees, contractors, shared services, or multiple applications.
Route account requests to Slack, Google Sheets, and Zapier.
Sample prompts for the builder
Choose a prompt, adapt it to your access process, or send it to the Makeform builder. The structure is an example, not a live result.
Audience
Managers requesting access before a new hire starts
Format
Role-based request with manager approval
Prompt size
358 chars
Example form structure
Role-based request with manager approval
Employee, role, department, and manager
Start date and work location
Which systems need accounts?
Role-based access profile
Exceptions and business reason
Suggested routing tags
Manager approved
Needs clarification
Ready to provision
Ask for a start date, account owner, and role-based access profile so IT receives an actionable request.
Step 1
Request
user, role, systems, and dates
Step 2
Review
manager confirms purpose and access
Step 3
Provision
IT creates accounts and records status
Step 4
Handoff
requester gets completion details
Why structure the request
Email threads omit start dates, system roles, approvers, or owners. A focused form makes them explicit before work enters the queue.
Collect identity, manager, location, start date, and systems in consistent fields.
Show CRM roles for CRM requests, elevated-access reasons when selected, and end dates for contractors.
Send submissions to reviewers and record whether IT needs clarification or has completed the account.
Account scenarios
Choose the closest workflow, then replace systems, roles, owners, and approval questions with your team's terms.
Bundle identity, department, manager, start date, standard applications, and a role-based access profile for onboarding.
Capture a sponsor, project, end date, external-sharing needs, and review owner.
Ask for the exact application role, team, region, environment, or record visibility needed instead of a vague request for access.
Document purpose, named owners, permitted users, credential custodian, review date, and the event that should retire the account.
Build the workflow
Generate the foundation, tailor it to your systems, then publish one intake route.
List who submits requests and which applications and account types IT supports.
Require identity, manager, date, system, and role. Add follow-ups for elevated or service accounts.
Send requests and their context to the appropriate inbox or Slack channel.
Test each request path and clarify labels that cause repeated questions.
Form vs email vs generic ticket
Compare whether each method preserves the identity, owner, system role, timing, and reason needed for review.
Field guide
Use these six sections as a checklist, reserving operational notes for IT.
People
Separate the submitter from the person receiving access, especially for manager or sponsor requests.
Role context
Job context helps reviewers select a standard profile. Ask about exceptions after establishing the normal role.
Systems
Use checkboxes for systems and conditional follow-ups for role, group, region, environment, or data scope.
Timing
Start dates guide preparation; end or review dates identify temporary access for later review.
Ownership
Record business and technical owners, plus who may use or manage the account.
IT tracking
Keep the final identifier, status, completion date, and unresolved issues beside the request.
Related tools
Connect account intake with application access, service tickets, software requests, and developer access forms.
Collect reasons, owners, and review context for higher-privilege administrative access.
Open toolGather application, environment, owner, scope, and intended-use details for API access.
Open toolCreate a broader front door for repeatable internal technology and service needs.
Open toolCapture incidents and support requests that do not require a brand-new account.
Open toolAsk for the business need, users, ownership, and application details before software review.
Open toolCollect repository, environment, role, and sponsor details for engineering access.
Open toolFAQ
Answers for IT admins and managers standardizing account intake.
It is structured intake for an employee, contractor, vendor, or service account. It records who needs access, why, when, the required systems and roles, the owner, and the reviewer.
Collect requester and user identity, manager or sponsor, role context, start date, systems, permissions, and reason. Add end dates for temporary users and owners, authorized groups, review dates, and retirement triggers for shared accounts.
Yes. Present systems as checkboxes, then show specific questions for each selection. A CRM can ask for role and region, while a developer tool asks for repository and environment.
Require a sponsor, contractor company, project, start and end dates, and minimum roles. Name the person responsible for reviewing continued access. Your organization sets approval and lifecycle rules.
Collect the manager's identity and confirmation, then route the submission into your review process. For distinct approval actions, histories, or sequential approvers, define and test that workflow before use.
No. Capture the access need, owner, system, role, and provisioning context, not passwords, recovery codes, or secret keys. Use your IT team's designated credential process.
Yes. Makeform is unlimited free for creating, editing, publishing, and collecting responses. The paid tier removes the Makeform badge; it does not unlock a response allowance.
Responses can reach the Makeform inbox, Slack, Google Sheets, or Zapier. Choose destinations that fit your process and test notifications and conditional paths before sharing.
Replace incomplete account emails with a consistent brief.
