Govern SharePoint Access in ServiceNow

Build an approved access lifecycle for a private SharePoint site.

Introduction

30 Second Summary

Access to a private team site often begins with a quick message to whoever manages it. That shortcut makes it hard to prove who approved access or why it was granted.

In this project, you will build a governed access-request workflow that connects ServiceNow to a private SharePoint team site called Project Atlas. You will move one test user from denied access to Microsoft 365 group membership while preserving the approval trail.

What You'll Build

You will demo Alex opening a once-blocked Project Atlas site after ServiceNow records the request, approval, and completed fulfillment task.

By the end of this project, you'll have:

A clear access-boundary demo where Alex has a license but still sees Project Atlas deny entry without group membership.
A structured request experience that captures Alex's email and business reason before routing the request for approval.
A grant lifecycle you can demonstrate from request to access. You can also explain where production identity automation replaces the lab's manual membership change.
Secret Mission: Extend the catalog and flow with a revocation path. Prove Alex loses access after group removal.

Are there any prerequisites?

Your Mac and Safari are enough for every setup step. The Microsoft trial may require payment information before you turn off recurring billing.

Before We Start

Before any setup, commit to the governed access lifecycle that anchors this project. A requester will seek Project Atlas access through an auditable approval process that ends with Microsoft 365 group membership controlling the private site.

Set Up the Two Sandboxes

Your governed access demo needs two independent environments. A ServiceNow Personal Developer Instance acts as the control plane for requests and approvals.

A Microsoft 365 trial tenant provides the user identity that will eventually access Project Atlas. Safari keeps your administrator session separate from Alex's test session.

In this step, get ready to:

Request an active ServiceNow PDI through the Developer Program.
Start a Microsoft 365 Business Basic trial with recurring billing turned off.
Create a licensed test user named Alex Morgan with an isolated browser session.

Create your ServiceNow PDI

The ServiceNow Developer Program provides a free PDI with administrator access. This sandbox will hold the catalog request and its audit trail in later steps.

Press Cmd+Space to open Spotlight on your Mac.
Type Safari into Spotlight and press Enter.
Visit the ServiceNow Developer Site in Safari.
Create your free Developer Program account through the registration form.
Sign in to the Developer Site with your new account.
Select Request Instance from your Developer Site dashboard.
Choose your preferred available ServiceNow release.
Select Request to request the PDI.

The Developer Site now shows the status of your instance request. Capacity determines whether the PDI is provisioned immediately.

No PDI available?

If your preferred release is unavailable, select Join Waitlist. Return to this step when the Developer Site confirms that an instance is available.

Help me troubleshoot PDI availability. You can also ask for peer guidance in the ServiceNow Developer Forum.

Select Start Building when the PDI is ready.

You should see your active PDI open with the current administrator user. That is the control-plane half of your lab ready for the workflow.

Start the Microsoft 365 trial

Microsoft 365 Business Basic includes SharePoint team sites. It also provides the identity controls needed for the Alex Morgan test account.

Why Microsoft 365 Business Basic?

This project needs browser-based administration and a private SharePoint team site. Business Basic supplies those services without requiring desktop Office applications.

The trial includes enough licenses for this lab. One license will belong to Alex Morgan.

Microsoft asks for payment information because the trial converts to paid service after 30 days. You stay in control by switching recurring billing off as soon as the tenant opens.

Visit the Microsoft 365 business plans page.
Select the free trial option for Microsoft 365 Business Basic.
Create the tenant administrator account through the signup form.
Provide payment information when Microsoft requests it.
Complete the security verification if Microsoft shows it.
Continue to the Microsoft 365 admin center after the tenant is created.

You should now see the Microsoft 365 admin center while signed in as the tenant administrator. The active Business Basic trial supplies the resource-plane half of the lab.

Select Billing in the left navigation.
Select Your products.
Turn off recurring billing for the Microsoft 365 Business Basic trial.

Good call. Your tenant now expires at the end of the trial instead of converting to a paid subscription.

Can't complete the trial setup?

Complete any payment or security checks shown by Microsoft before continuing. Use the tenant administrator account created during signup when changing the billing setting.

Help me troubleshoot my Microsoft 365 Business Basic trial setup.

Create Alex's isolated test session

A Microsoft 365 license lets Alex sign in to the tenant. Group membership will determine whether Alex can enter the private Project Atlas site.

Alex needs a separate browser session so the tenant administrator login cannot affect the access test. Safari Private Browsing isolates that session from your normal window.

Return to the Microsoft 365 admin center from earlier.
Select Users in the left navigation.
Select Active users.
Select Add a user.

The new-user form opens. This form creates the licensed identity that you will test against Project Atlas.

Enter Alex as the first name.
Enter Morgan as the last name.

The display name should now read Alex Morgan.

Enter alex as the username.
Advance to the product license step.

The license selector now shows the products available in your trial tenant. Alex needs the Business Basic trial license for the later SharePoint test.

Assign the Microsoft 365 Business Basic trial license to Alex Morgan.
Select Finish adding to create the account.

The completion page now provides temporary credentials for Alex. Temporary credentials act like a real password, so the next action keeps them out of screenshots.

Save Alex's temporary credentials in your password manager.
Select File in Safari's menu bar.
Select New Private Window.
Leave the Private Window open for Alex's isolated Microsoft 365 session.

You should see a dark Smart Search field with white text in the Private Window. This confirms Safari is keeping Alex's future sign-in separate from the administrator session.

Before the final check, predict which environment should show the active PDI and which account should appear in Microsoft 365.

Switch back to the ServiceNow Developer Site tab from earlier.
Select Start Building to enter the active PDI.

You should see the active ServiceNow PDI open with the current PDI administrator user available.

Switch back to the Microsoft 365 admin center tab from earlier.
Select Users in the left navigation.
Select Active users.
Select Alex Morgan from the user list.

You should see Alex Morgan with username alex and the Microsoft 365 Business Basic trial license assigned. Both sandboxes are now ready for the access-boundary test.

Can't find Alex or the license?

Return to Active users and check that the account appears as Alex Morgan. Open the account details to confirm the Business Basic trial license is assigned.

Help me troubleshoot the Alex Morgan test account.

Your ServiceNow control plane and Microsoft 365 resource plane are ready. Next up, you will create Project Atlas and prove that a license alone does not grant access to its private SharePoint site.

Prove the SharePoint Access Boundary

Your two sandboxes are ready. Project Atlas now needs a protected SharePoint home before any request workflow can govern access.

A private team site uses an associated Microsoft 365 group to decide who can enter. In this step, you will test that boundary through Alex's isolated Safari session.

In this step, get ready to:

Create a private Project Atlas team site from the Standard team template.
Test the saved Project Atlas URL as Alex without adding Alex to the site's group.

Create the private Project Atlas site

SharePoint creates an associated Microsoft 365 group when you create a team site. Keeping the site private gives Project Atlas a clear membership boundary.

Switch to SharePoint by selecting it from the app launcher in the Microsoft 365 admin center.
Select + Create site.
Choose Team site.
Select the Standard team template.
Enter Project Atlas as the site name.
Set Privacy settings to Private - only members can access this site.
Select Create site.
Finish the site creation without adding Alex Morgan.

You have built the protected resource your workflow will govern. Project Atlas opens as a private team site.

What Did SharePoint Create?

The team site automatically created an associated Microsoft 365 group. That group holds the site's member list.

You left Alex out during creation. This gives you a clean baseline for the access test.

Test access as Alex

The Project Atlas URL gives both identities the same test target. Alex's private session keeps the test separate from your administrator session.

Copy the full Project Atlas URL from Safari's address bar.
Record the copied URL here: your Project Atlas site URL.
Switch back to the Safari Private Window from earlier.
Sign in as Alex Morgan with the saved temporary credentials.

Before you load the site, do you think Alex's Business Basic license is enough to open Project Atlas?

Paste your Project Atlas site URL into Safari's address bar.
Press Enter to load Project Atlas.

You'll see that Project Atlas does not load for Alex. This is the intended baseline.

Alex has a Microsoft 365 license. Alex does not have Project Atlas group membership.

Why Is Alex Denied?

The license lets Alex use SharePoint as a service. The private site's Microsoft 365 group decides whether Alex can enter Project Atlas.

This applies least privilege by granting access only to named members. Your request workflow will create evidence before that membership changes.

Does Project Atlas Open for Alex?

Confirm the Safari Private Window is signed in as Alex Morgan.
Confirm the address bar matches your saved Project Atlas URL.
Remove Alex through the Project Atlas group membership list in the Microsoft 365 admin center if Alex was added during site creation.

Ask for help with diagnosing why Alex can open the private Project Atlas site.

You have proved the key access boundary. Next, you will build a ServiceNow request that captures who needs access and why.

Build the ServiceNow Access Request

The Project Atlas denial proved that Alex's Microsoft 365 license does not grant SharePoint access. Direct messages asking for access would leave no structured evidence.

This step uses ServiceNow Service Catalog to turn the request into a consistent form. A named approval group gives every submission a clear destination.

In this step, get ready to:

Create the SharePoint Access Approvers group with your current PDI admin user as a member.
Create the active Request SharePoint Access catalog item.
Add two mandatory questions to the requester-facing form.

Create the approval group

A named group gives the next step a stable approval target. Changing its membership later does not require rebuilding the request form.

Switch back to your ServiceNow PDI from earlier.
Select User Administration in the All navigator.
Select Groups.
Select New.
Enter SharePoint Access Approvers in Name.
Select Submit.

The saved group provides the container for your approver membership.

Open SharePoint Access Approvers from the groups list.
Scroll to the Group Members related list.
Select Edit.
Select your current PDI admin user in Collection.
Select Add.

You should see your PDI admin user move into the group membership selection.

Select Save.

Good progress. The request process now has a named approval destination with an active member.

Create the catalog item

A catalog item converts an informal access request into a repeatable intake record. Empty automation fields keep this item ready for the flow you build later.

Select Service Catalog in the All navigator.
Select Catalog Definition.
Select Maintain Items.
Select New.

The blank Catalog Item form holds the requester-facing details plus the automation fields used by later steps.

Enter Request SharePoint Access in Name.
Enter Request access to Project Atlas. in Short description.

You should see the item name plus its purpose at the top of the form.

Confirm Active is selected.
Confirm Workflow is empty.

The item is active without using a legacy workflow.

Confirm Execution Plan is empty.
Leave Flow empty.

All three automation fields should now be empty.

Select Submit.

You should see Request SharePoint Access in the catalog item list as an active item.

Can't find the catalog fields?

Confirm you created a Catalog Item from Maintain Items.
Confirm you did not populate Workflow.
Confirm you did not populate Execution Plan.
Confirm you did not populate Flow.

Help me check my ServiceNow catalog item configuration.

Add the required variables

Catalog variables standardize the information each requester provides. The first variable identifies the Microsoft 365 account that needs access.

The Variables related list sits near the bottom of the item record, so finding it can take a little scrolling.

Open Request SharePoint Access from Maintain Items.
Scroll to the Variables related list.
Select New.

Select Email in Type.
Enter Requested user email in Question.

You should see an Email variable labelled Requested user email.

Enter requested_user_email in Name.
Enter 100 in Order.

The internal name now identifies this variable inside future flow actions. Its order places the question first on the form.

Select Mandatory.
Select Submit.

You should see requested_user_email in the Variables related list with order 100.

The second variable captures the reason behind the access request. That explanation becomes reviewable evidence for the approver.

Select New in the Variables related list.
Select Multi Line Text in Type.

You should see the variable form configured to accept a longer written response.

Enter Business justification in Question.
Enter business_justification in Name.

The requester-facing question now has a matching internal name for later flow steps.

Enter 200 in Order.
Select Mandatory.

The second question is mandatory with order 200, so it follows the email question.

Select Submit.

You should see both variables in the related list. The email variable has order 100. The justification variable has order 200.

Before you select Try It, predict whether both questions will appear as required.

Return to the Request SharePoint Access catalog item.
Select Try It.
Inspect Requested user email for its required status.
Inspect Business justification for its required status.
Leave the catalog item unsubmitted after this check.

You'll see both questions marked as required on the requester-facing form. This proves that ServiceNow captures an account identifier plus a reviewable reason before the item can be ordered.

Form missing a required question?

Return to the affected variable from the Variables related list.
Confirm its Catalog item points to Request SharePoint Access.
Confirm Mandatory is selected.
Confirm the question value matches the variable you intended to create.

Help me troubleshoot missing or optional variables on my ServiceNow catalog item.

Your intake foundation is ready. ServiceNow now captures consistent identity plus justification data for every future Project Atlas request.

Your catalog request is ready for governance. Next up, you'll connect it to approval and fulfillment records while Alex remains blocked from Project Atlas.

Add Approval and Fulfillment

Your Service Catalog request form in ServiceNow now captures Alex's identity. It also captures his business justification.

That form records intent. It does not authorize the request or provision access to the private SharePoint site.

This step adds a group approval record. It also adds a traceable fulfillment task for the work that follows.

In this step, get ready to:

Build a flow that sends each Requested Item to the approver group.
Create a waiting Catalog Task that carries the request details.
Run Alex's request through approval before retesting the protected site.

Create the approval flow

A Service Catalog trigger starts the flow whenever someone orders the item. The trigger's Requested Item becomes the record that moves through approval.

The new-flow form asks for a name before it opens the flow canvas.

In the PDI from earlier, enter Flow Designer in the All filter.
Select Flow Designer under Process Automation.
Select + New.
Select New Flow.
Name the flow SharePoint Access Request Fulfillment.
Create the flow with that name.

You will see a new flow canvas for SharePoint Access Request Fulfillment.

Set the trigger to Service Catalog.

The canvas now shows a Service Catalog trigger at the top of the flow.

Add Ask for Approval beneath the trigger.
Set Record to the trigger's Requested Item.

The approval action now follows the record created by the catalog order.

Route the approval to SharePoint Access Approvers as the approval group.
Set Rules to Anyone approves.

The action now requires one member of the approver group to authorize the Requested Item.

Save the flow.

You should see the Service Catalog trigger followed by Ask for Approval on the canvas.

Add the waiting fulfillment task

Approval records the decision. A Catalog Task turns that decision into assigned work with the original request details attached.

Add Create Catalog Task after Ask for Approval.
Set Requested Item to the trigger's Requested Item.

The task is now linked to the same Requested Item that passed through approval.

Set the task's short description to Add the requested user to Project Atlas.
Assign the task to SharePoint Access Approvers.

The task now tells the fulfiller what to do. It also gives the approver group responsibility for the work.

Add requested_user_email to Catalog Variables.
Add business_justification to Catalog Variables.

The task now carries the identity and justification captured by the catalog form.

Enable Wait for the Catalog Task.
Save the flow.

Why make the task wait?

With Wait enabled, the flow pauses while the Catalog Task remains active. Closing the task later gives the flow a clear fulfillment checkpoint.

Activate the flow.

You should see SharePoint Access Request Fulfillment marked as active.

Flow Won't Activate?

Confirm the flow has a Service Catalog trigger.
Check that Ask for Approval uses the trigger's Requested Item.
Check that Create Catalog Task also uses the trigger's Requested Item.

Ask for help with the flow configuration: Help me troubleshoot why my ServiceNow Service Catalog flow will not activate.

The active flow still needs a connection to the catalog item. The item's empty Workflow and Execution Plan fields prevent another process from competing with it.

Use All to return to Service Catalog.
Select Catalog Definition.
Select Maintain Items.
Open Request SharePoint Access.
Confirm Workflow remains empty.
Confirm Execution Plan remains empty.
Set Flow to SharePoint Access Request Fulfillment.
Save the catalog item.

The catalog item now shows SharePoint Access Request Fulfillment in its Flow field.

Order and test the request

The active flow is ready for a real request. Alex's order will prove that the approval record creates assigned fulfillment work.

Select Try It on the Request SharePoint Access catalog item.

You will see the requester-facing form with both mandatory questions.

Enter Alex Morgan's Microsoft 365 email address from the temporary credentials you saved earlier in Requested user email.
Enter Alex needs Project Atlas access for approved project work in Business justification.

The completed form now identifies Alex. It also explains the business need for access.

Place the catalog order.

The order creates a Requested Item for Alex's access request.

In All, select Self-Service.
Select My Approvals.
Open the approval for Alex's Request SharePoint Access order.
Select Approve.

The approval is now recorded. The flow continues to Create Catalog Task.

Return to the approved Requested Item.
Open its linked Catalog Task.
Confirm its short description is Add the requested user to Project Atlas.
Confirm it is assigned to SharePoint Access Approvers.
Confirm it includes requested_user_email.
Confirm it includes business_justification.

That's the governance chain working. Alex's request now has an approval decision plus an open task waiting for fulfillment.

No Catalog Task After Approval?

Confirm the approval record shows an approved decision.
Confirm Create Catalog Task sits after Ask for Approval in the active flow.
Confirm the catalog item's Flow field contains SharePoint Access Request Fulfillment.

Ask for help tracing the missing task: Help me find why my approved ServiceNow request did not create a Catalog Task.

Before you retest, do you expect the approved request to have changed Alex's SharePoint access?

Switch back to Alex's Safari Private Window from earlier.
Open the saved Project Atlas URL.

You will still see that Alex cannot open Project Atlas. This is the intended shortfall.

ServiceNow has authorized the request and assigned the fulfillment work. No Microsoft 365 group-membership change has occurred.

Your approval trail and fulfillment task are working. Next up, you will carry out the recorded membership change before closing the task with evidence.

Fulfill the Request and Verify Access

The approval trail is in place. Alex is still blocked because the Catalog Task has not changed Project Atlas membership.

ServiceNow has authorized the request. Microsoft 365 still needs the matching group-membership change before SharePoint admits Alex.

In this lab, you perform that provisioning action manually. You then record the evidence in the task so the workflow can finish.

In this step, get ready to:

Add Alex Morgan to the Project Atlas Microsoft 365 group.
Verify that Alex can open the private Project Atlas site.
Complete the Catalog Task with fulfillment evidence.

Add Alex to the Project Atlas group

Membership in the Microsoft 365 group created with Project Atlas controls access to the private site. Adding Alex fulfills the approved request at the resource plane.

Switch back to the Microsoft 365 admin center from earlier.
Open Active groups.
Select the Project Atlas Microsoft 365 group.
Select Membership.
Select Members.
Select Add members.
Choose Alex Morgan.
Select Save.

You should now see Alex Morgan in the Project Atlas group member list. The approved request has produced a real access change.

Alex Missing From the Member List?

Confirm that you selected the Project Atlas group created with the private site.
Open Members again.
Confirm that Alex Morgan appears in the member list.

Help me check why Alex Morgan is not appearing as a Project Atlas group member.

Verify Alex can open Project Atlas

The saved URL isolates one variable: Alex's group membership. The Safari private session lets you repeat the access check with the same test user.

Switch back to Alex's Safari Private Window from earlier.

Before you refresh, do you expect the same licensed account to stay blocked now that its group membership has changed?

Refresh the saved Project Atlas URL.

You should now see the Project Atlas team site instead of the access-denied page. Alex can enter because the account is now a group member.

That is the access boundary working. The same licensed user now reaches the private site because the approved membership change is complete.

Alex Still Blocked?

Confirm that the Safari Private Window is signed in as Alex Morgan.
Return to the Project Atlas group member list.
Confirm that Alex Morgan appears as a member.
Refresh the saved Project Atlas URL again.

Help me troubleshoot why Alex still cannot open Project Atlas after joining the group.

Close the Catalog Task with evidence

Access is working, but fulfillment is complete only when the Catalog Task carries evidence. The work note records the exact membership change that satisfied the request.

Switch back to the ServiceNow PDI from earlier.
Return to the open Catalog Task linked to the approved Requested Item.
Enter Added Alex Morgan to the Project Atlas Microsoft 365 group. Verified that Alex Morgan can open the private Project Atlas site. in Work notes.
Select Update to save the fulfillment evidence.

Return to the same Catalog Task from the approved Requested Item.

You should see the saved work note identifying the Project Atlas group. The note also records that Alex Morgan was the verified user.

Before you close the task, what should the waiting flow do once the task is no longer active?

Set State to Closed Complete.
Select Update.
Return to the updated Catalog Task.

You should see the task showing a State of Closed Complete. The waiting flow can now finish because the task is no longer active.

Task Not Staying Closed?

Return to the Catalog Task linked to the approved Requested Item.
Confirm that State shows Closed Complete.
Select Update again if the state change was not saved.

Help me troubleshoot why my ServiceNow Catalog Task is not staying in the Closed Complete state.

What Does the Manual Step Prove?

ServiceNow preserves the request record. It also preserves the approval and fulfillment evidence.

The lab uses a human fulfiller to change Microsoft 365 group membership after approval. A production identity integration would perform that membership change while preserving the same governed handoff.

You have now closed the gap between authorization and provisioning. Alex can enter Project Atlas while ServiceNow retains the completed audit trail.

Secret mission

Add a Revocation Path

Extend the Request SharePoint Access experience so it can remove access as well as grant it. You will branch the live flow, complete a Revoke request for Alex Morgan, remove Alex from the Project Atlas group, and prove that the private site blocks Alex again.

Clean Up Your Resources

Choose whether to keep, pause, or delete this lab. It currently has no ongoing charge.

Cost warning

A Microsoft 365 Business Basic trial automatically converts to paid service after 30 days if recurring billing is on.

Recurring billing is already off in your tenant. The trial therefore expires at the end of its term without charging the saved card.

The ServiceNow Personal Developer Instance is free.

Resources you used:

The Project Atlas SharePoint team site with its associated Microsoft 365 group.
The Alex Morgan test account with its assigned trial license.
The Microsoft 365 Business Basic trial subscription with recurring billing off.
The ServiceNow PDI containing the catalog item, variables, approver group, flow, requests, approvals, and Catalog Tasks.

Keep everything running

Leave the lab intact if you want to revisit the grant and revocation lifecycle. You do not need to remove any resources.

Confirm recurring billing remains off on the Your products page under Billing in the Microsoft 365 admin center.
Keep the saved Project Atlas URL for future access tests.
Sign in to the ServiceNow Developer Site before the PDI reaches 10 days of inactivity.
Use the Microsoft 365 trial only until its expiry date.

Pause - I'll come back to this later

Step away while preserving the evidence you want to keep. An idle PDI can hibernate with its data preserved.

Save screenshots of the completed Grant and Revoke Catalog Tasks.
Save a screenshot of Alex Morgan's final denied-access result in the Safari Private Window.
Keep the saved Project Atlas URL with your screenshots.
Confirm recurring billing remains off on the Your products page under Billing.
Return to the ServiceNow Developer Site before the PDI reaches 10 days of inactivity.

Delete - I don't want to use this again

Choose this option when you have finished with the lab. Save any screenshots you want to keep before removing its resources.

What site deletion removes

Deleting the group-connected Project Atlas site also deletes its associated Microsoft 365 group and connected resources.

Delete Project Atlas:

Use Active sites in the SharePoint admin center to locate Project Atlas.
Select Project Atlas.
Select Delete.
Confirm the deletion by selecting Delete.

Delete Alex Morgan:

Locate Alex Morgan on the Active users page under Users in the Microsoft 365 admin center.
Open Alex Morgan to reach the Delete user page.
Choose the handling option for Alex Morgan's license.
Choose the handling option for Alex Morgan's email.
Choose the handling option for Alex Morgan's OneDrive.
Select Delete user.

Release the ServiceNow PDI:

Open Manage my Instance on the ServiceNow Developer Site.
Select Actions.
Select Release instance.
Select a reason for releasing the PDI.
Confirm the release by selecting Release instance.

Close out the Microsoft 365 trial:

Confirm recurring billing remains off on the Your products page under Billing.
Allow the Microsoft 365 Business Basic trial to expire at the end of its term.

Nice Work!

You made it! You built a governed access lifecycle in ServiceNow for a private SharePoint site using Microsoft 365 group membership.

You've learned how to:

Demonstrate a private access boundary by showing that Alex remains blocked without group membership. You then granted membership to prove that access follows the group.
Build a ServiceNow request workflow with mandatory identity data. You also captured business justification before routing each request through group approval and a waiting Catalog Task.
Preserve an auditable fulfillment trail through approvals and completed tasks. You can now explain where a licensed supported identity integration replaces the lab's manual group changes in production.
Secret Mission: Extend the same catalog item and flow with Grant and Revoke branches. You proved revocation by removing Alex from the Project Atlas group and confirming that the private site blocks Alex again.

Ready to quiz yourself?