Administrator guide

Guided Setup

The 14 steps that take Warde from a fresh install to working requests, access reviews and a joiner process.

Guided Setup is the first thing to open after you install Warde. It walks through 14 steps in order. Each step reads the instance every time you open it, so you can stop at any point and come back later: nothing is lost, and the page opens on the first step that still needs you.

#Open Guided Setup

In the navigator, open Warde > Guided Setup, or go to /x_66256_warde_setup.do. From the Admin Workspace, the Setup item on the left rail opens a launcher with the same link.

You need the admin role or the Warde administrator role, x_66256_warde.idam_admin. Guided Setup is the only Warde page that accepts plain admin, so a platform administrator can start setup before anyone has been named. Every link on the page opens in a new tab, so the wizard stays where you left it.

#How the page works

The left rail lists every step with a mark and a one-line summary:

A step holding edits you have not saved shows unsaved on the rail, and those edits survive a save on another step. If a step cannot be checked, its summary reads "Could not be checked. See the system log." and the rest of the page still works.

Three steps cover things Warde cannot see from inside the instance: whether your portal links to Warde (step 12), whether a real request has gone all the way through (step 13), and whether your joiner, mover and leaver processes call Warde (step 14). For those, you confirm the step yourself once you are satisfied.

#The 14 steps

#1. Name the Warde administrators

You need two roles in place before anything works. The administrator role opens the Admin Workspace. Without the requester role the request forms are empty for everyone and nobody can open an access review.

In Grant a role, choose a role, then give it to one person, a group, or a role people already have:

Granting to a person or a group saves straight away. Granting to a role people already have opens a new role containment record with both roles filled in, because the platform does not let an application write those records itself. Check it, save it, then refresh the step. You can grant roles here but not remove them: open the user, group or role record to remove one.

Reviewers need only the requester role. If you grant it to named groups rather than everyone, put your managers and entitlement owners in one of them. Warde also ships a reviewer role, x_66256_warde.reviewer, but nothing depends on it, so the step does not offer it.

If your instance has no snc_internal role, the Requester card offers Set up the daily job, with a scheduled job script that grants the requester role to active users once a day.

Remove the platform administrators. Warde installs with its administrator role contained in admin, so every platform administrator can run setup on day one. Once you have named administrators of your own, the card Platform administrators can administer Warde enables Open the record to remove. Delete the record it opens. From then on, only the people you named can see or change identity data. The button stays disabled until someone is named, so Warde is never left with no administrator.

The step is done when at least one administrator is named directly (a role inherited through admin does not count), the requester role reaches somebody, and the containment under admin is removed. Until that last part, the step shows orange.

#2. Connect an engine

An engine is a system Warde reads access from and writes access to, such as SailPoint or Microsoft Entra ID. The Engines card lists every engine with its connector, endpoint, credential and health.

Select Add an engine and fill in:

The box under the connector lists what that connector can and cannot do.

Warde cannot set the engine's address for you, because the platform refuses connection and alias records to every scoped application. The alias summary links to the connection record in Connections & Credentials; open it and enter the endpoint URL there. Each connector guide gives the exact URL.

Save the engine, then select Test connection. The step is done when at least one engine passes the test and no enabled engine is missing an endpoint or a secret. The ServiceNow task engine needs no connection and does not count toward this step.

To remove an engine, select Delete. Warde first tells you how many records depend on it, then deletes them in the background.

Engine-specific setup is in the connector guides: SailPoint Identity Security Cloud, SailPoint IdentityIQ, Microsoft Entra ID Governance and ServiceNow tasks.

#3. Bind accounts to users

Each account an engine reports has to be matched to a ServiceNow user. For each engine, choose the field on each side that identifies the same person:

• Engine attribute: the account attribute, such as employeeNumber or email.
• ServiceNow user field: the sys_user field holding the same value, such as employee_number or email.

Select Save on each engine. Warde matches accounts as they are imported. An account that matches no user is still imported, but it belongs to nobody: it cannot be used in requests and never appears in an access review. Warde marks it as an orphan so you can find it.

The instance-wide default pair lives in two system properties, x_66256_warde.correlation.default_attribute and x_66256_warde.correlation.default_field. An engine with its own pair uses that instead.

The Import maps card lists the seven transform maps Warde ships, in the order they run, and marks each one Ready, Changed, Switched off or Missing. Changed means the map writes to a different table, matches rows on a different key, or runs in a different order from the one Warde ships. A changed match key makes every sync add a second row instead of updating the first. You need the admin role to see this card.

#4. Import data

This step imports what each engine has: its applications (Warde calls them collections), the entitlements in them, the accounts, and who holds what today. Each feed lands in a staging table first and is then copied into Warde's own records.

Select Sync now on an engine. The sync runs in the background, and each run appears under Import Sets. Select Refresh to update the counts: collections, collection bindings, entitlements, entitlement links, accounts, access and the last sync time. If a count stays at zero, the column where it stops tells you which feed to look at.

A scheduled job repeats the import on its own after this. The step is done when at least one entitlement and one account have been imported.

#5. Build your approval policies

An approval policy says who must approve before access is granted, in what order, and what happens if no approver is found. Warde ships one policy, Line manager.

Select Build a policy to open the Approval Policy Wizard in a new tab. See Approvals for how to design one. The list on this step marks any policy with no rules: a request that reaches a policy with no rules stops.

The step is done when at least one active policy exists and every policy has rules.

#6. Decide who approves

Warde looks for an approval policy on the entitlement, then on the access bundle it came in, then on the collection it belongs to. This step sets what happens when none of those names one. All of it is saved with Save approval settings.

The step shows orange if a chosen default policy is inactive or has no rules, or if the exception group is unset, inactive or has no active members.

#7. Decide who approves a removal

People give access back with the Remove Access and Remove Access Bundles forms, and with the Remove Access button beside each item on My Access. Choose who approves those removals:

• The person who has the access (default)
• Their line manager
• The removal approval rules: the default removal approval policy from step 6
• Nobody: no approval is needed

A removal that needs approval always gets a removal request, so the approval has a record to sit on. A removal that needs none is made the way step 11 says, the same as a reviewer's Remove. This step is always done; the default is a sound choice.

#8. Fallback fulfilment

When Warde cannot add or remove access itself, it creates a ServiceNow task for someone to do it by hand. Each collection names the group that gets its tasks. This step sets the groups for everything else, saved with Save fulfilment settings:

The promise is counted on the Warde fulfilment hours schedule, Monday to Friday, 9 to 5. Open the schedule from the step to change the hours or add your public holidays.

The step is done when the fallback group exists, is active and has an active member. See Manual fulfilment for how those tasks work.

#9. Onboard your collections and entitlements

A collection is one application: its entitlements, its owner, the group that does its manual work, how its requests are approved, and who can ask for it. Imported collections start hidden from requesters. Select Open Collection Onboarding to take one through the onboarding wizard and make it live. See Collections and entitlements.

The step is done once one collection is live. While any live collection has no support group, the step lists them.

#10. Publish the end-user experience

Everything people outside IT see: the forms they use, the emails Warde sends, and how My Access looks in your portal. Every choice here is yours, and Warde changes nothing in your portal on its own.

How people ask for access. Warde ships five catalog items. Each card shows whether the item is live and has Switch on or Switch off, See what a requester sees and Open the catalog item.

An item is live when it is active, switched on, and placed in a catalog category or an Employee Center topic. Put each item where your people already look. The Who can see these items card explains the user criteria Warde relies on, and the three things not to change.

Who people can request for. Choose how far a requester can reach when asking on someone else's behalf: themselves only, themselves and their direct reports (the default), everyone below them at any depth, or anyone in the organisation.

The emails Warde sends. Warde does not email about requested items; your existing catalog notifications keep doing that. It sends its own emails for access reviews and a few request events. Here you can add HTML for a header and a footer, set the CSS every Warde email uses, and preview each email with example records. Nothing is sent from the preview. The card also checks whether your approval notifications show approvers the request's comments. If outbound email is switched off on the instance, the card says so.

How Warde looks in your portal. Choose whether requests are quoted by the requested item number (RITM, the default) or the request number (REQ). The card Match the access page to your branding shows how to restyle My Access with a CSS record on your portal theme.

The step is done when at least one request item is live, the Request Access flow is active, and the item's user criteria are in place.

#11. Set up access reviews and campaigns

Reviewers work on the Reviews tab of My Access in your portal, and review emails link to it. All of this is saved with Save review settings:

Reviews in Employee Center My Tasks offers three prefilled records that put review tasks on the My Tasks page. Warde cannot write them itself; open each, check it and save it.

How long audit evidence is kept sets the retention for Warde's audit history, between 365 and 2,562 days, or 0 to keep it forever. The default is 2,557 days, seven years.

The Campaigns card shows campaign counts and the next run of the Warde campaign scheduler job, and warns if that job is off. See Access reviews for how to define a campaign.

#12. Put Warde in your portal navigation

Until you add them, people reach Warde only through links in emails, and once the email is gone they cannot find the page again. The step gives the address of each page to add:

• My Access, the page warde_my_access
• Request Access
• Remove Access

Add them to your Employee Center topics and quick links, or to your Service Portal's main menu. Warde writes nothing here. Warde can find some links to these pages but not all: a link in a home page widget, or a link with the address typed in, does not show. Check your portal yourself, then confirm the step.

#13. Go live

• Scheduled jobs lists every Warde job, whether it is active, and its next run. Every job should be active. See Settings and scheduled jobs.
• Logging sets the log level: Error, Warn (the default), Info or Debug. Leave it at Warn in production.
• Before you tell anyone: select Submit a test request and follow it until the access is granted, using the fulfilment queue and the audit events.
• Tell people about it: nothing you have set up so far tells your people that Warde exists. The step suggests a portal carousel banner.

If separation of duties is off, the step reminds you that no request is checked for conflicts. Confirm the step once a real request has gone all the way through.

#14. Connect joiners, movers and leavers

Warde does not detect joiners, movers and leavers. Your HR system or identity platform already does, and knows more about a new joiner than the instance does. Have that process call Warde, and Warde grants the access bundle the person should hold, records why, and tracks the work like any other request.

The step shows the REST endpoint and code samples for both routes, and lets you choose what Warde does by default: all of it (engine grants and catalog tasks), only engine grants, or only catalog tasks. See Joiners, movers and leavers.

The step waits until you have at least one active birthright bundle. Confirm it once each of your processes calls Warde.

#Setting up in a sub-production instance first

If you set Warde up in a development or test instance and promote it, each step reaches production one of three ways:

Some settings travel differently from the rest of their step:

• The fulfilment schedule (step 8) and an item's connection to an Employee Center topic (steps 10 and 12) are not saved in an update set. Export them as XML, or make the same change in production.
• The default binding pair (step 3), the log level (step 13) and the lifecycle default (step 14) are system properties, so they travel in the update set.
• Campaigns (step 11) are made by production and are not promoted.

#Other wizards

Guided Setup links to two other wizards, both open from the Warde menu and from the Admin Workspace's Setup launcher. Both need the Warde administrator role.

• Collection Onboarding, /x_66256_warde_onboard.do: eight steps that make one imported collection requestable. See Collections and entitlements.
• Approval Policy Wizard, /x_66256_warde_policy.do: four steps that build an approval policy and preview it against a real person. See Approvals.