Our organization, like many others, handles access requests for all applications through our IT Support desk. Additionally, documentation is required and must be approved by the user’s department manager before the access can be granted. After just recently migrating the entire company’s intranet over to SharePoint 2010, I wanted to allow users to request access, so I made sure the Manage Access Requests was selected by default for all resources. However, within a week of moving it over I’m getting requests for all sorts of things in my inbox every day, even from our kiosk service accounts in the employee break room or at terminals, which are both locked down intentionally. I don’t mind the access requests, but there needs to be a consistent way of handling requests that complies with our internal standards.

I did some research into the Access Request email message that comes from SharePoint, thinking maybe I can modify the timer job, workflow, email content, etc. Nothing. In fact, the very same discussion is held in a TechNet article located here. Bummer, this would have been ideal.

So what’s the next best step? Modify the reqacc.aspx file in C:program filescommon filesmicrosoft sharedweb server extensions14templatelayouts.

Here’s what the original page looks like:

** WARNING: Make a copy of the original file BEFORE modifying! Making changes to the layouts folder in SharePoint is always at your own risk! If for any reason your changes are unsuccessful, you can always delete that file and place the copied original back in the folder to restore functionality!

That being said, here’s what I did to create a custom Request Access page:

1. Navigate to your layouts folder, typically located at c:program filescommon filesmicrosoft sharedweb server extensions14templatelayouts
2. Make a copy of the reqacc.aspx file and put it somewhere safe. Make NO changes to this copied file!
3. Open the other reqacc.aspx file (not the copy) in your editor of choice.
4. Near the bottom, locate the following section of code:

<td id="RoleDescription" class="ms-descriptiontext"><br/><SharePoint:EncodedLiteral runat="server" text="<%$Resources:wss,reqacc_entermsg%>" EncodeMethod='HtmlEncodeAllowSimpleTextFormatting'/></td>
</tr>

This is the section of the page that says “Type your request, and then click Send Request.” Deleting it breaks the page because SharePoint is looking for specific elements in the page, so all I did was hide it by adding the following CSS attribute:
<td id="RoleDescription" style="display:none" class="ms-descriptiontext">

This will override the CSS class settings and hide the element altogether. Do the same thing to the textarea below it, to prevent users from entering in anything:

<td class="ms-descriptiontext">
<textarea name="txtareaMessage" id="txtareaMessage" rows="0" cols="0" class="ms-descriptiontext" runat=Server></textarea>
</td>

This is the textbox that says “Supply a description of the action you were taking and the URL you were trying to reach.” I hid the entire element by adding the same style attribute like so:
<td class="ms-descriptiontext" style=”display:none”>
<textarea name="txtareaMessage" id="txtareaMessage" rows="0" cols="0" class="ms-descriptiontext" runat=Server></textarea>
</td>

5. If you want to enter a custom message or instructions for the user to follow, I put that in place of the input button in the next table row below the textarea, located here:

<td>
<input type="submit" value="<%$Resources:wss,reqacc_sendreq%>" id="btnSendRequest" accesskey="s" runat="Server"/>
</td>

Here is a sample of what I replaced it with:

<td>
<font size="4pt">To request access, please fill out a User Access Request Form located <a href="internal link to InfoPath form">here</a>. Make sure the resource you need access to is listed in the form, including the URL listed above.</font>
</td>

Save the file and the changes are immediate. The end result will look something like this:

You could theoretically change this page however you want, but I liked the existing simplistic layout, it got to the point and provided the end user with enough information. Of course, custom application pages can be made and used in SharePoint nearly anywhere.  Hope this helps!