Introduction: What is a PDI?

in ,

This article is for all those new to ServiceNow, just getting their feet wet into the platform! (And for you experts, I’ll have a section at the bottom for you too!)

You may have heard the acronym, PDI, which stands for Personal Developer Instance. It’s almost kind of like one of those small personal pizzas! These are small instances you can request using a ServiceNow Developer account. These are one of the best tools to use, so you can get hands on, live experience in a ServiceNow instance, without worrying about impacting a company instance.

To get a PDI, it’s pretty straightforward.

  1. Navigate to https://developer.servicenow.com/dev.do and create a new account

  2. Click the button to Request an Instance

  3. Pick the version you want (you may consider the same version your company is using, or the newest available)

  4. Wait for the provisioning to occur (usually is pretty fast under 5min)

  5. Click the “Open Instance” button to be directed to the instance

  6. You’ll be automatically logged in as an admin user to your own personal instance!

See ServiceNow’s PDI Guide to learn more!

Things to be aware of

  • 10 Day Inactivity Period and TOS - To be able to provide these instances, ServiceNow had to restrict their capabilities, so that they could be released when not in use, and could be put in hibernation. There are jobs that check usage like clicks/activity. Tampering with these jobs and keeping your instance alive is against their terms of service.

  • PDIs have limited system resources - These instances are extremely small, single node instances, low CPU, RAM, DB capabilities. Really just don’t expect too much, and they are not intended to be used by multiple users at the same time.

  • PDIs have a unique instance naming scheme - They will also look like “dev12345.service-now.com”. Technically you could wrap a proxy to make it look like a different URL, but the instance URL is unique to PDIs.

  • Don’t expect a high level of support for PDIs, it’s a free offering from ServiceNow, so it’s mostly understood that it’s a “YOU” problem for better or for worse.

  • PDIs don’t have access to the application repository, any apps you want to publish, you will need to save off and publish as an update set.

  • PDI Data centers - You don’t get a PDI based on your location, you just get one. This could also have some impacts on latency. You can always check the datacenter code from the node name under stats.do

PDI Best Practices

  • Backup everything. Use github or export your XMLs after every development session at the end. Just think of it like saving your work. PDIs can be very unreliable, and you could quickly lose your work if you miss the inactivity window, the restore fails, or your instance gets killed by some back luck.

  • Don’t put any company/sensitive data in a PDI. While they should be safe, protect yourself out there!

  • Try out your code in a PDI first - if it goes rogue in a PDI, it is pretty easy to just release the instance if something goes terribly wrong and start over.

Advanced PDIs

If you’ve spent much time in PDIs, you might start to consider how you can automate all the setup steps and get back up and running fast.

Props to Mark Roethof, he has written a series of articles about the scripts and things you can write to automate loading PDI settings.

Here are list of things you could automate on your PDI:

  • Installing Plugins

  • Setting user settings (favorites, timezone, date/time format)

  • Applying your favorite utilities via a batch update set

  • System config like MID server, email config, or more!

I’m so thankful for PDIs, that enable learning, hobby development, and as a proof of concept instance, and more!