Share This:

Whether you are just starting out with Remedy OnDemand or you are an experienced administrator, there are some pieces of information that you will find useful to have close to hand for administration, project work, upgrades and for working with Remedy OnDemand Operations.


I have listed the 10 key pieces of information that it is worth making a note of for troubleshooting, testing and upgrading Remedy OnDemand.


  1. Customers are responsible for the management of any customisation to their Remedy OnDemand instance (BMC Remedy OnDemand Customisation Policy). Keep a list of your customizations with a brief description of the change made and why. Note down the contact details of the person who did the customisation. Some examples are customizations made to:
    • Form changes e.g. new fields
    • Indexes
    • Labelling
    • Login/logout pages
    • Redirects (custom hyperlinks)
    • Tables
    • Workflow
    • This isn't an exhaustive list essentially a customisation is anything that you modified using BMC Remedy Developer Studio
  2. A list of any custom reports that you have created or reports that you have customized. This will be useful when you come to upgrade and for testing change.
  3. A list of your integrations with a brief description of the integration, with endpoints and contact details for the people who completed the integration.
  4. Configuration, Customisation and Integration documentation – if you worked with a third party to configure Remedy OnDemand they should provide you with this documentation. For complex customizations & integrations you will have design documentation which should be stored safely for future troubleshooting and testing
  5. Any test cases that you have used for your user acceptance testing. For example test cases for your customizations, integrations onboarding, or previous upgrades. You will likely be able to re-use them and you will need them for testing changes.
  6. Details of your SSL certificates including expiry dates for example email, LDAP and any integrations.
  7. Test logins for example for SAML and integrations.
  8. Location or steps to generate test data if applicable. Certain customers are not be able to use production data for testing for data security purposes.
  9. Browsers used and versions. This can be very helpful for troubleshooting.
  10. Any specific IP addresses that are being used for example for integrations.