A software access request asks for a role in an application your organization already has, and it records who approved that role and why the work needs it. Name the application as the vendor shows it, choose the lowest access level that does the task, and give an end date when the access depends on a project or contract. The form records the request; someone with the right permissions still makes the change inside the application.
Software request form: 70 average monthly searches.Google Ads Keyword Planner · 2026-10-09 · United States
Use this form to ask for access to an application your team already has, or for a different role in it. Software you need to buy is a separate request. Do not type passwords or recovery answers here, because IT does not need them to grant access.
Your access request is recorded. The form does not contact your approver, so ask them to confirm it in writing before anyone changes the account.
Use the name the application shows on its sign-in screen, not a nickname your team uses in chat.
Choose the lowest level that lets you do the task. Administrator access needs a closer review than read-only access.
Describe the work, for example: review monthly invoices and export the aging report. 'To do my job' does not give an approver enough to decide.
| Field | Type | Required | Why you ask it |
|---|---|---|---|
Requester name | Short text | Required | Matches the request to a person. The account name in the application should match this name. |
Work email | Required | Lets IT or the application owner confirm the account and ask a follow-up question. | |
Approver email | Required | Identifies the manager or data owner who can say the access is needed. The approver confirms the role, not only the requester's wish. | |
Application nameUse the name shown on the sign-in screen | Short text | Required | Identifies the system so IT can find the right administrator. |
Access level neededRead-only or viewerEditor or contributorAdministratorNot sure, please advise | Dropdown | Required | Administrator rights need a closer review than read-only access, so this answer changes how the approver checks the request. |
Business taskFor example: review monthly invoices and export the aging report. | Long text | Required | Lets the approver decide whether the role fits the work. |
Account typeNamed account for meShared login for a teamNot sure | Single choice | Required | Shared logins make it hard to tell who made a change, so ask for a named account wherever the application allows one. |
ApprovalThe approver should answer this part, or confirm it in writing. | Section header | Keeps the sign-off question apart from the details the requester supplies. | |
Manager has approved in writingYes, approved in writingNot yet | Single choice | Required | Records whether approval came before the request was sent. The form cannot verify the approval itself. |
Access needed until | Date | Optional | Ends temporary, contractor or project access on a set date. Leave blank for ongoing staff access that the approver still reviews. |
Anything else IT should knowDo not write passwords, one-time codes or recovery answers here. | Long text | Optional | Captures context such as a pending change of role or a limit on the number of licenses. |
Attain OS stores each request, and a scheduled job processes new submissions on an hourly schedule in production. Only the form's creator is notified, so the person who grants access should check the grid as well.
Treat the approval answer as a prompt, not as proof. Look for the approver's written yes before you change anything, and keep that message with the request.
Compare the access level with what the task needs. If the work requires more than the role gives, send the request back to the approver rather than granting a higher role by default.
Export CSV from the submissions grid when a manager or security lead reviews which accounts were requested and when they should end.
A request for a 'manager' role leaves the approver guessing when the application offers editor and administrator levels. Use the application's own role names, and put the job reason in the business task.
People ask for the highest role to avoid a second request. Ask for the lowest role that does the task, and let the approver raise it once the work shows it needs more.
When someone changes role, their old access stays until someone asks for it to be removed. Name in the business task what the new role no longer needs, so the change removes as well as adds.
The form records what was asked, by whom and why. Someone with the right permissions still changes the account inside the application, and the form does not make that change.
Often, yes, when you are buying a new license or subscription. A software access request is for using a product your organization already has or has already approved. Keep the two requests separate so the approver knows exactly what they are agreeing to.
Name the application, the access level, the business task, the approver and whether the account is named or shared. Add an end date when the access depends on a project or contract. Leave out passwords and recovery answers.
There is no download on this page. You can copy the field list and adapt the access levels to the roles your applications really use. Keep the approver and end-date fields, since the approver needs both to decide whether access should be granted and when it stops.
Say so in the business task field. The approver or application owner can decide whether a different role, or a separate tool, fits the work.
Choose a category and a form type in the wizard. Answer three Atty Suggestions questions, then give the form a title. Atty builds the fields in the background. Edit the fields and ask Atty to refine them, then publish and share the /f/ link.
