Admin Guides / Customising Warde
Customising Warde
What to use instead of changing Warde's own files, what a changed file costs you at upgrade, and how a fix file from Warde support reaches your instance.
Warde is built to be set up through its settings and wizards. Almost everything organisations ask to change is a setting, an approval policy or a record of your own, and an upgrade keeps all of those. Changing one of Warde's own files, such as a script, widget, page, flow, catalog item or ACL it installs, works on the day and costs you at every upgrade after it.
What to use instead
| You want to | Use |
|---|---|
| Change who approves, or add an approval stage | Approval policies |
| Ask the requester more questions for one application | Guided questions |
| Make Warde's emails look like yours | Header, footer and styling in Guided Setup step 10 |
| Change what the request and approval emails say | Your own catalog notifications, which read what Warde writes onto the request and approval |
| Stop one of Warde's emails | Switch that notification off |
| Make My Access match your portal | A CSS record on your portal theme, from Match the access page to your branding in Guided Setup step 10 |
| Put the forms where your people look | Catalog categories, Employee Center topics and portal menus, from Guided Setup steps 10 and 12 |
| Change timings, reminders, retention or who may request for whom | Settings, most of them in Guided Setup |
| Start access from your HR or identity process | The joiner, mover and leaver API |
| Use your own IdentityIQ provisioning workflow | The engine's workflow setting |
Records Warde ships that you can change lists the shipped records made for you to edit, such as the fulfilment hours schedule. An upgrade keeps your version of those, which is what you want.
Ask before you change a file
Most requests to change a file turn out to be a setting. Before you change anything:
- Look in Guided Setup. Each of its 14 steps shows the settings for one part of Warde and what each one does.
- Raise a case at support.warde.app. Describe what you are trying to achieve, and the change you had in mind if you have one. Warde support will tell you which setting does it, fix the defect in Warde if it is one, or record it as a feature request and tell you when it ships. Asking costs nothing and is part of your support.
What a changed file costs at upgrade
When you change a record Warde installed, the platform records your version as a customer update. When you install the next Warde release, the platform keeps your version of that file and skips the release's version. It lists the file as a skipped record in System Diagnostics > Upgrade History.
That means:
- Fixes stop reaching that file. A defect Warde fixes in it stays in your copy, through every later release, until you put the file back.
- Your copy runs against newer files. Warde's files call each other, and an older copy of one beside newer copies of the rest is a combination nobody has tested. It can fail in ways that look like a Warde defect.
- Every upgrade needs a person to compare your copy with the release's copy and decide what to keep.
- Support stops for that area. Warde support cannot diagnose a part of the application whose files differ from the release, so cases about it wait until the file is put back.
Records you create yourself, such as a report or a notification of your own that reads Warde's tables, are not touched by an upgrade. Check them after each upgrade anyway, in case a release changed a field they read.
If you change a file anyway
- Make the change in sub-production first, in an update set of its own whose name starts with Warde customisation, so it is easy to find later.
- Keep a list of every Warde file you changed and why.
- After every Warde upgrade, open System Diagnostics > Upgrade History, open the Warde upgrade and review its skipped records. For each one, keep your version or revert to the release's version.
- When you raise a case, name every Warde file you have changed.
- To put a file back, revert it from its skipped record in Upgrade History, or from the record's Versions list, choosing the version the Warde install brought.
Guided Setup step 3 already marks an import map you have changed as Changed.
How fixes reach you
Fixes normally arrive in a Warde release from the ServiceNow Store. While you wait for one, Warde support may give you a setting to change, a data repair script for your administrator to run, or a way to switch the faulty part off.
A fix file from Warde support
When a defect cannot wait for the next release, Warde support may send you the fixed file or two as an update set, in an XML file. The files are the copies the next release ships, and every customer with the same defect gets the same file.
Every customer update in it is marked Replace on upgrade. That tells the platform to replace those files when you install the next Warde release, so your instance goes back to running the released files, with the fix in them. Without the mark, the platform would treat the fix as your own customisation and skip the next release's copy of those files.
To load it:
- In sub-production, sign in as an administrator who also holds the Warde administrator role,
x_66256_warde.idam_admin. - Open System Update Sets > Retrieved Update Sets, select Import Update Set from XML and choose the file from your case.
- Open the update set and select Preview Update Set. If the preview lists a problem, stop and add it to the case.
- Select Commit Update Set.
- On the update set's Customer Updates list, add the Replace on upgrade column if it is not shown, and check that it is true on every row. Set any row that reads false to true.
- Test the fix with Warde support on the case.
- Load the same XML file into production through your change process, and check the Replace on upgrade column there too. Use the file from the case, not a copy of your sub-production update set.