Skip navigation

Developer Community

8 Posts authored by: Dawn Jurek Employee

Automation is the name of the game for streamlining your organization’s processes, and adopting the ServiceNow platform is the first step to transforming your business.

 

So we have to ask - are you still condemning one of your employees to sit and perform tests manually, over and over, each time you’ve modified forms or upgraded your instance? Or are you the poor soul stuck with that task?

 

By setting up automated testing that you can reuse and modify, you take the error-prone human factor out of the loop. The Automated Test Framework (ATF) allows you to create and run automated tests on your ServiceNow instance to confirm that the instance still works as designed after being upgraded or modified. In this installment of our NOWSupport best practices series list, the following best practices will help you leverage the power of ATF.

 

But first, if you want to understand the basics of ATF, check out this video on our NowSupport YouTube channel:

 

 

And now, within the guiding principle of Always safeguard your production instance comes our first best practice:

 

Always run ATF, or any other testing framework, within a dev or test instance but never within prod

 

This best practice goes hand-in-hand with why you shouldn’t develop on your production instance. You may be tempted to run a quick test on your production instance to verify a minor change, but never succumb to that urge. Why? Here are a couple scenarios:

  • A test can change data that may be designed to trigger actionable events, like sending out emails. You don’t want to have to explain to your manager why your test sent emails to your entire customer base, do you?
  • A test can impersonate users with extensive security access. Even a minor oversight could allow test user Joe Admin to run amok.

 

Start a test with an Impersonate step to ensure the test user has the required roles

 

We recommend that you always configure an Impersonate step as the first step in your test. To do this, select Impersonate as the first test step, and specify the user to impersonate. In doing so, you can ensure that the test user has the required roles and behaves like that specific user.

 

Why bother to employ this step if you run the test as the test designer user? Because your test could break if someone changes the test designer user roles, or disables the test designer user.  Or, you may find that the test can’t access a record or form properly based on the correct user roles. Setting up an impersonate step helps you avoid all these pitfalls.

 

Be aware of the browser throttling issue and how it can affect your tests

 

What causes ATF tests to fail? There are several possible root causes for this, including the tester failing to open the Client Test Runner, logging out of the session, or clearing the browser history on another tab, which affects all tabs. But inadequate central processing unit (CPU) power due to browser “throttling” is often at fault. Our previous best practices post, How to avoid ATF Testing Failures, gives you the lowdown on this issue.

 

When testing a form, set fields critical to your business process to ensure they all work

 

When creating a test for a form, you may be tempted to take shortcuts and only set the form’s required fields, or fields that you’ve edited. We recommend setting form fields critical to your business process, so that every time you run the test you’re verifying these fields.

A field must be present on the form in order to set it with Set Field Values.

 

Use the Test Logs and Test Transactions to troubleshoot test errors

 

And finally, here’s a shout out to the Test Logs and Test Transactions that provide a treasure trove of information for troubleshooting. Check them first before contacting customer support – the reason why a test is failing is probably recorded in one of these lists.

 

These are easy to find. After running your test, click Go to Result and the Test Results page displays.

ATF_test_results.jpg

 

  • Click the Test Logs tab to see a record of all the detailed information that the test can track, including browser console logs and other errors:

ATF_test_log.jpg

 

  • Click the Test Transactions tab to see a record of all system transactions recorded during the test:

ATF_test_transactions.jpg

 

Ready to get started with ATF? In this video, we show you how to set up your first ATF test:

 

 

For more information:

 

Getting started with the Automated Test Framework (product documentation)

Build and run your first automated test (product documentation)

Jakarta Juices Up Automated Test Framework (ATF) (blog post)

 

--

 

Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We’ve found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series targets those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you’d like us to cover in this series, please let us know in the comments below.

 

To access all of the blog posts in this series, see our NOWSupport best practices series list.

ServiceNow provides you with the flexibility to customize forms so that they can mirror your business processes. But sometimes tinkering with default values can be tricky. In this installment of our best practices series, we look at how changing the default State field on one form can affect other forms as well. But not to worry: we also show you how to use the magic of dictionary overrides to avoid this pitfall.

 

Consider this Oops scenario:

 

In the base system, the default value for the State field on the Incident form is New, but you want the default value to be In Progress instead:

Incident form showing State choices final.jpg

 

So you right-click the State label to show the choice list for this field, and filter it for the Incident table. You note that the Value corresponding to In Progress is 2:

Choices for State field on Incident table final.jpg

 

Then you go back and right-click the State field on the Incident form again to configure the dictionary for this field, changing its Default value to 2:

Change default value to 2 final.jpg

 

It works! The default State value for new incidents is now In Progress. But there are also some unintended consequences. For example, the Problem form now displays a default State of Known Error. That’s not right!

Problem form showing default State as Known Error final.jpg

 

And some other forms are affected as well.

 

What went wrong?

 

If you had looked carefully at the dictionary entry for the State field when you changed the default value, you would have noticed that the change you made affected the Task table—not just the Incident table:

Dictionary entry for State field-Task table final.jpg

 

That’s because the Incident table is a child class whose parent is the Task table. The Incident table inherited the State field from the Task table, and any changes made to this dictionary entry affect the Task table and all child tables extending from it. So, changing the default value of the State field on the Task table also changed the default State value for a bunch of other tables, including the Problem table.

 

The proper way to change the default State value for the Incident table without affecting the Task table or its extended tables is to use a dictionary override. First, we change that default State value back to 1, which is what it should be for most forms.

 

What are dictionary overrides and how do I create them?

 

Dictionary overrides allow system administrators to define certain field settings on an extended table differently from those on the parent table without affecting the parent table or its extended tables. Dictionary overrides are defined in the dictionary entry record for the field on the parent table. For example, here’s the dictionary entry for the State field on the Task table, scrolled down to display the Dictionary Overrides related list:

Dictionary Overrides for State field on the Task table final.jpg

 

Two dictionary overrides already exist for the State field on the Task table—one applies to the Change Request table and the other to the Standard Change Proposal table.

 

To define a new dictionary override to set the default State value on the Incident table to 2, click New and fill in the form, like this:

Define dictionary override for Incident Table final.jpg

 

Here you can see which other settings can be overridden for the State field. As check boxes are selected, additional fields are displayed to specify the details for each override.

 

Now, with this new dictionary override, the incident form displays a default State value of 2, and the Problem form displays a default State value of 1, exactly as they should:

Incident-new record with State value of 2 final.jpg

Problem-new record with State value of 1 final.jpg

 

How dictionary overrides affect extended tables

 

Dictionary overrides are inherited by extended tables, so it may be necessary to define additional overrides to change the value of fields on extended tables. For example, if you define the default value of cmdb_ci.install_status to be 3, and create an override for the same field on cmdb_ci_hardware to be 5, all tables extended from the Hardware table will also default to 5. So if you want the default cmdb_ci_computer.install_status to be 3, you will need another override.

 

Best Practice: Align state values across applications

 

A related best practice is to align the State field values. These aren’t always aligned in the base system, but generally, a State of 3 means closed, regardless of whether the record is an incident, a problem, or a change.  If you alter the states, try to keep them aligned across all the applications. This may be easier said than done, but it is useful. For example, you can then make a report on the Task table, and see all closed tasks with one filter, rather than lots of OR conditions.

 

Want to learn more about tables, records and fields? Check out this video:

 

 

For more information, see:

 

--

 

Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We’ve found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series targets those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you’d like us to cover in this series, please let us know in the comments below.

 

To access all of the blog posts in this series, search for "nowsupport best practices series."

Imagine this: Two airline passengers, John and Mary, log in to an airline’s seat reservation webpage to select their seats. A query business rule determines which seats were available to each passenger—based on factors such as their airfare and frequent flyer status—and then the system displays the same seating chart to both of them. They both select the same seat and submit the form, but Mary's reflexes are a little faster than John's, and she hits Submit a fraction of a second before he does.

 

seat_selection.jpg

 

If the system didn’t double-check and discover that the seat was no longer available when John clicked Submit,...

business_rules_seat.jpg

 

...there could be an awkward situation at boarding time.

awkward_moment.jpg

 

Fortunately, a before business rule checked for data that may have changed during the time lapse between John’s filling in the form and submitting it. So the database was not updated to assign John the same seat that Mary had secured just a millisecond earlier, and they won’t have to fight over the seat. Thanks to this business rule, an awkward situation was avoided!

seat_notice.jpg

 

In this installment of our best practices series, we look at what business rules are, and how they run.

 

What is a business rule?

 

A business rule is a server-side script that runs when a record is displayed, inserted, updated, or deleted, or when a table is queried. Common uses are to check for data that may have changed during the time lapse between filling in a form and submitting it, as in the example above, or to automatically change values in form fields when certain conditions are met.

 

When business rules run

 

Using business rules at the right point in the business rule processing flow helps prevent unpredictable results and performance issues related to those rules.

Timing is Everything.png

This flowchart illustrates when business rules run, relative to database operations on the record—such as the system displaying the form, the user updating the form, and the database being updated. In general, business rules apply consistently to records regardless of whether they’re accessed through forms, lists, or web services. However, display business rules are only used by forms—not by lists or web services.

flowchart.png

The When field on the Business Rule form, shown here, indicates the point at which the business rule script runs, relative to database operations shown in the flowchart above. To display the When field on the form, the Advanced check box must be selected. This business rule runs before the current object is saved to the database.

 

Business rule form final.jpg

 

Here’s a list of base system business rules. You can view business rules in your own instance by navigating to System Definition > Business Rules. In this case, the list is personalized to display the When column. The most commonly used business rules are before and after rules.

 

business_rules_list_when.jpg

 

This table explains when business rules run and provides example use cases.

 

When value
When the rule runs
Example use case
displayBefore the form is presented to the user, just after the data is read from the database.To provide client scripts access to server-side objects.
beforeAfter the user submits the form but before any action is taken on the record in the database.To update information on the current object. For example, a business rule containing current.state=3; would set the State field on the current record to the state whose numeric Value is 3.
afterAfter the user submits the form and after any action is taken on the record in the database.To update information on related objects that need to be displayed immediately, such as GlideRecord queries.
asyncWhen the scheduler runs the scheduled job created from the business rule. The system creates a scheduled job from the business rule after the user submits the form and after any action is taken on the record in the database.To update information on related objects that do not need to be displayed immediately, such as calculating metrics and service level agreements (SLA).

 

You can often use an async business rule in place of an after business rule. Async business rules are similar to after rules in that they run after the database commits a change. Unlike after rules, async rules run in the background simultaneously with other processes. Async business rules allow the system to return control to the user sooner but may take longer to update related objects.

 

Business rule examples

 

Here are examples of a before and an after business rule.

 

Business rule that runs before database update

 

The insert_incident business rule runs before the database is updated:

 

Business rule form no annotations.jpg

 

When this rule runs, the current.number variable is assigned the next available incident number, and a message is displayed to the user:

 

Script from insert_incident.JPG

Business rule that runs after database update

 

The SNC - ITIL - Close Related business rule for the Change Request table runs after the database is updated:

 

SNC - ITIL - Close Related.JPG

 

When this rule runs, it closes all related child change tasks and related problems:

 

SNC - ITIL - Close Related script.JPG

 

To learn more about configuring business rules, check out this video on our NOWSupport YouTube Channel:

 

 

For more information, see:

 

--

 

Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We’ve found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series targets those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you’d like us to cover in this series, please let us know in the comments below.

 

To access all of the blog posts in this series, search for "nowsupport best practices series."

We empower our customers to automate processes and make them run as efficiently as possible. Take client scripts, for example. In the ServiceNow system, a client script is a piece of JavaScript code that runs on the client browser. These scripts are commonly used to make forms smarter—tailor the fields to individual users, populate or validate field values, display messages, and so on.

 

If you're just getting started with client scripts, check out this video on our NOWSupport YouTube channel:

 

 

Client scripts can be really helpful and powerful little chunks of code, but they also have a potential dark sidethey can impact performance for the user. In this installment of our best practices series, we look at six ways you can keep client scripts from bogging down your processes.

 

Six ways to improve client script performance

  1. Use a UI Policy instead
  2. Reduce server lookups
  3. Avoid global client scripts
  4. Add the isLoading check to onChange scripts
  5. Add the newValue check
  6. Run server calls as late as possible within the script

 

Use a UI policy instead of a script

You can use UI policies to make form fields mandatory or optional, visible or hidden, or read-only or writable when certain conditions are met. It’s a good idea to use a UI policy instead of a script whenever you can. UI policies execute efficiently, and unlike with scripts, you can control the order in which multiple UI policies execute. Plus they’re easy to create, which saves you the trouble of writing the scripts.

ui_policies_list.jpg

 

And here’s a tip. You can run a script as part of a UI policy, but that can be tricky to troubleshoot down the road. Stick with the supplied UI policy functions if you can.

 

Reduce server lookups

Retrieving data from the server takes time, so make as few server requests as possible, and retrieve only the data you need.

 

Another way to reduce server lookups is to use g_scratchpad (in a display business rule) and GlideAjax (in any script) instead of g_form.GetReference() and GlideRecord. The first pair are more efficient because they let you choose which fields you retrieve from the server, whereas the second pair retrieve the entire record.

 

Avoid global client scripts

A global client script is one where the selected table is Global. Since these scripts load for every table, they load for every page in the system, including home pages and Service Catalog pages, where they’re very rarely needed.

 

Instead, choose a specific table for the script. If you choose a base table like Task [task] or Configuration Item [cmdb_ci], the script is loaded for pages that refer to that table or any of its child tables, but not for other pages. This helps these other pages load faster.

 

Add the isLoading check to onChange scripts

You typically don’t need to run onChange scripts when a form loads because they would already have run the last time a value on the form changed. To keep an onChange script from running when the form loads, check the isLoading flag at the start of the script and stop the script if it’s true, like this:

 

    if (isLoading)

        return;

 

Add the newValue check

Typically you don’t want to run a script that references a particular field if the form doesn’t contain a value for the field. To avoid this, check newValue and run the rest of the script only if it’s non-null, like this:

 

    if (newValue) {

    // rest of script follows

 

Do server calls as late as possible

Often a script will check various items available on the client (like the isLoading and newValue checks we saw earlier) before running the rest of the script. Be sure to put server calls (like GlideAjax) after these checks to prevent wasting time on the server calls.

 

 

_________________________________________________________________

 

By following these tips, you can ensure that your client scripts behave and support your processes, rather then impeding them.

 

For more information, see:

--

 

Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We’ve found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series targets those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you’d like us to cover in this series, please let us know in the comments below.

 

To access all of the blog posts in this series, search for "nowsupport best practices series."

Coordinating application development within your organization can be like herding cats. One developer's code may collide haphazardly with someone else's, creating change conflicts that must be resolved. Developers may not be sending changes to—or retrieving changes from—a common instance. Total chaos could erupt! ServiceNow provides a number of development tools that may be the catnip to tame your development process disarray.

 

What tools does ServiceNow provide for development?

 

Team Development is another option that you may be using. In this latest installment of our best practices series, we describe how to tame this complex but powerful system by deploying changes properly.

 

What is Team Development?

 

Team Development supports parallel development on multiple, sub-production ServiceNow instances, where each instance acts as a source repository, or branch. Individual developers use separate sub-development (sub-dev) branches to work on different features, applications, or product releases at the same time. In the development environment, the sub-dev instances are peers with a common development parent (dev-parent). Changes from all developers working in the sub-dev instances are integrated and stabilized in dev-parent prior to testing and eventual release to production.

 

Best practice for deploying changes when using Team Development

When using Team Development, push changes only from sub-dev instances to a dev-parent instance. Team development functionality is not intended for pushing changes to test or production instances. To deploy changes in the production pipeline, use update sets instead:

 

Team_development.png

 

Why not push changes to test or production instances?

If it becomes necessary to back out a change on a team development instance, the backout goes all the way back down the chain, also undoing the work on the source instance. This can cause major problems on test and production instances. Update sets, on the other hand, can be backed out without affecting the source instance.

 

Also, using update sets in the test and production pipeline, as shown above, allows you to clone from production to test instances when your test users need newer data, without impacting your development process and instances.

 

For more information on Team Development, see

 

Check out the Developers Portal to learn more about the ServiceNow development tools at your disposal; no cat herding required. And in the meantime, don’t let Team Development run amok with your development process.

 

--

 

Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We’ve found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series aims to target those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you’d like us to cover in this series, please let us know in the comments below.

 

To access all of the blog posts in this series, search for "nowsupport best practices series."

Here's the dilemma of the day - you’re developing applications on your DEVelopment instance, and you need to clone your PRODuction instance to your DEV instance to test the changes. But here's the catch - one or more of those applications are still in-development. What should you do?

 

Let's say you throw caution to the wind and start the clone anyway. When the clone is complete and you refresh your DEV instance (clone target) from PRODuction (clone source), you find that the in-development applications are completely missing or are the wrong versions on the target instance, post-clone. Arg! What happened? In this sixth installment of our best practices series, we look at three different ways you can preserve those in-development apps.

 

What happens to in-development applications when you clone over the development instance

After a clone, the target instance will have whatever version of the application the source instance had when cloned. For example, if the source had the latest version, the target will have the latest version post-clone. The source will still be a sys_app (sys_store_app applications are read-only) application, meaning it can be developed further. However, if the latest application version is 1.2 and the clone source has version 1.1, the post-clone target will have a developable application that is version 1.1, the same as the source instance. If the clone source has no version of the application installed, the target will, likewise, have no version of the application available post-clone.

 

 

Post-clone development best practices

If you have applications in development on an instance that will be used as a clone target, before cloning to that instance, do one of the following with all of your in-development applications to allow continued post-clone development:

source_control.JPG

  • Publish the application to an update set, and install it back to the target instance, post-clone.

publish_to_update_set.JPG

  • Install the most recent version of the application to the source instance prior to the clone.

 

Dilemma solved -  you can clone your PROD instance and keep your fledgling apps. Happy developing!

 

--

 

Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We’ve found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series aims to target those topics so that you and your organization can benefit from our collective expertise.

 

See Annotate scripts and customizations with comments for the first installment on script comments.

See Limit the Number of Users with the Admin Role for the second installment on user roles.

See Where to avoid linking to a reference field when configuring a list for the third installment on list configuration.

See Developing on your production instance for the fourth installment on development.

See When to create a new table vs. when to extend for the fifth installment on application development.

 

To access all of the blog posts in this series, search for "nowsupport best practices series."

Anyone who has ever administered a web site or a ServiceNow instance can probably relate to this dilemma. You need to make a tiny change, such as adding a field to a form, or activating a plugin, and you're really pressed for time. Why not just quickly make the change on your production, or PROD, instance? What could happen; it's a minor change, right? In this third installment of our best practices series, we look at why you should never develop in production, and what you should do before making any changes to PROD.

 

Why you should never develop in a production instance

Sometimes it may be tempting to knock out small changes in PROD, but changes that seem minor can have unexpected and far-reaching effects.

 

For example, when you activate the Timeline Visualization plugin, Project Management V3 is automatically activated as a dependency, which could produce unwanted results. Before activating any plugin, make sure you understand which additional plugins get activated automatically, and which features they affect. These are described in the product documentation, like the example shown below.

time_visualization_doc.jpg

Development best practice

Perform all development in a sub-PRODuction instance and thoroughly test everything that’s affected before deploying to PRODuction. This includes even small changes, such as adding a field to a form, or activating a plugin, updating an access control list (ACL) rule, or tweaking a client script.

 

Before making ANY change to your PROD instance:

  • Make the change in a sub-PROD instance.
  • Make sure you understand how the change may affect downstream features, functions, and data.
  • Use small update sets that can be backed out more easily than a large one.
  • Thoroughly test the changed feature and any dependent features or functions.
  • Ideally, have other stakeholders assist with testing because they follow their normal workflow, which an admin may not be familiar with. This helps identify any issues that aren't evident to an admin user but may show up for users with other roles (such as itil). If other stakeholders can’t help with testing, use impersonation.
  • Always have a back-out plan, which includes backing up all records that will be affected by the change.

 

Leave your PROD pristine, and take all your tweaking and testing offline to your sub-PROD instance.

--

 

Behind the scenes here at ServiceNow, the Knowledge Management team works closely with subject matter experts to disseminate critical information to our customers. We’ve found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series aims to target those topics so that you and your organization can benefit from our collective expertise.

 

See Annotate scripts and customizations with comments for the first installment on script comments.

See Limit the Number of Users with the Admin Role for the second installment on user roles.

See Where to avoid linking to a reference field when configuring a list for the third installment on list configuration.

 

To access all of the blog posts in this series, search for "nowsupport best practices series."

Have you ever coded a complex function or customization, only to look at it later and realize you forgot to annotate it with comments, or skipped this step to save time? In this first installment of our best practices series, we look at the importance of accurately commenting your scripts and customizations.

 

Why is commenting on your scripts and customizations so important?

The script or customization details may be obvious to you today but may not be clear to you or others who must use or update the item in the future. Providing helpful comments as part of the development and upgrade process is well worth the effort and can save you and others a lot of time and trouble later. Most code is read many more times than it is written. Give your future self (and colleagues) insight into your thoughts! Here's what we recommend.

code sample 1.jpg

 

Annotating scripts and customizations best practices:

When writing scripts or customizing records, follow these best practices to avoid confusion.

  • Add clear and accurate comments that provide relevant information. Comments can include such as what the script or record does, its inputs and outputs, the business justification, and configuration requirements.
  • For scripts, use the proper style and tags required to start and end comments in the specific scripting language. It’s best practice to comment every substantial section of code, describing what the intent is behind it so that others looking at it later will understand how it works.
  • For other records, add descriptions to help users and developers understand its content and functionality. Important records to describe include business rules, UI actions, and access control list (ACL) rules. Most ServiceNow records have at least one field for descriptions or comments, such as the Description field. This field is not always visible by default and may need to be added by configuring the form.
  • Where applicable, include cross-references to related records or business requirements to provide additional information and context.
  • When you update a script or record, also update the comments, as needed.

code sample 2.jpg

 

Behind the scenes here at ServiceNow, the Knowledge Management team works closely with subject matter experts to disseminate critical information to our customers. We’ve found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series aims to target those topics so that you and your organization can benefit from our collective expertise.

 

To access all of the blog posts in this series, search for "nowsupport best practices series."

Filter Blog

By date: By tag: