Skip navigation

This is a old post I had on my earlier blog. I thought I might as well bring it up here to try to clear out how the cloning works.

 

First let's just talk about how the cloning works in a light version:

 

  1. You request the cloning with the System clone->Request Clone. Remember that the data you are cloning are from last night backup. So if you just changed something, you have to set the clone date for tomorrow instead if you want your last changes to be cloned.
  2. Now it looks at the "Preserve data" table and see what data on the target it should save. The data is stored somewhere else(magically) and will be restored after the clone
  3. Copies over everything to the target. If the table is in the "exclude tables" it only copies over an empty table.
  4. Then it copies over the "preserved data" that was stored before the copy.
  5. Runs the post-clone cleanup scripts.

 

 

How to save data on the target:

 

System Clone->Preserve Data. Here you specify which data you want to save on the target. You can take a whole table or you can set conditions like everywhere else in ServiceNow to just get a specific records from a table.

 

Now, preserve data does one thing, and that is make sure that the data on the target exists after the clone. It doesn't stop data from the source to be copied over. So if you only fill in the "Preserve Data". It will have data from both the source and the target. Example is the table "update sources" which holds information from which instance you get your updates from. If you put that table in "Preserve Data" it will keep your target source, but it will also copy over the sources "update sources". In real life this will probably look like if  you clone production to test, you suddenly have the productions update sources, which is test...

 

So what you need to do is to put the table in the "exclude tables" as well. Then it will first only copy over an empty table, then copy back the preserved data from the target.

 

The "Exclude audit and log data" checkbox:

 

There is also one checkbox I want to talk about and it's "Exclude audit and log data". This checkbox is checked as default and will stop a huge chuck of data to be copied over. And most of the time it's not needed. But it means for example that workflows isn't copied over, so if you after the clone go look into change requests that were copied over, they won't have a workflow connected to them. And that also means for example that the UI Action "Show workflow" isn't visible. It also excludes the audit data which means that the activity log for those records are messed up with time stamps and so.  The fix for this is of course to uncheck the field, but unless you have good reason to do this and copy over an extra large amount of data, I recommend not to do it. Since you should still be testing with new records/tickets anyway to see that it all works as intended.

 

If you want to dig deeper into it, feel free to visit the documentation: System clone

 

//Göran

 

sn-community-mvp.pngSymfoni Logo Color Box.jpg

//Göran

ServiceNow Witch Doctor and MVP
-----------------------------------
For all my blog posts: http://bit.ly/2fCzj1g

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."

Other posts related to Themes

"Helsinki Gray" UI16 Theme

Istanbul Theme Properties Visual Guide

Kingston Theme Properties Visual Guide

 

As a follow-up to my Istanbul Theme Properties Visual Guide post, this one describes the Theme properties for UI16 in the Jakarta release.

 

Test Theme Record

Here's the return of the ugly Theme record, updated for Jakarta:

 

/* Jakarta Test
    Created by Jim Coyne - https://community.servicenow.com/people/jim.coyne

    This is to help show what elements are affected by the CSS colors - PLEASE, PLEASE, PLEASE DO NOT ACTUALLY USE THIS THEME FOR REAL  :-)
    It uses HTML color names to hopefully make it a little easier to understand and find the color

    The comments include a copy of the UI16 default value:
        https://docs.servicenow.com/bundle/jakarta-servicenow-platform/page/administer/navigation-and-ui/reference/r_DefaultCSSStyle.html

    Refer to this post for more information:
        https://community.servicenow.com/community/develop/blog/2017/07/19/jakarta-theme-properties-visual-guide
*/

/* Mostly Banner */
$navpage-header-bg: DodgerBlue  /* #303a46 - banner background  */
$navpage-header-color: Aqua  /*  #ffffff - banner title text  */
$navpage-header-button-color: Coral /*  no default, not documented - logged-in user name + Connect, Help and Settings icons   */
$navpage-header-divider-color: FireBrick  /*  #455464 - banner separator line  */
$navpage-button-color: BlueViolet  /*  #fff - Update Set and Application icons + Navigator icons + Connect icons  */
$navpage-button-color-hover: Yellow  /*  #7EC24F - banner icons + clear search text icons + Navigator buttons when clicked  */


/* Mostly Navigator */
$navpage-nav-bg: BurlyWood  /*  #303a46 -  Navigator and Sidebar header and footers + unselected Navigator and Connect tabs background + History time separator background  */
$navpage-nav-bg-sub: Pink  /*  #455464 - Navigator and Sidebar backgrounds + background for Applications, Favorites and History entries  */
$nav-highlight-main: LightSkyBlue  /*  #3D4853  - Module, Favorite, History, Connect and Help item when clicked    */
$subnav-background-color: SlateGray  /*  #455464 - Module background  */
$navpage-nav-app-text: Black /*  #cfd4d8 - Application, Favorite and History text + Connect and Help text  */
$navpage-nav-color-sub: Tomato  /*  #bec1c6 - Module text  */
$navpage-nav-app-text-hover: DarkTurquoise   /*  #ffffff - Selected Module, Favorite, History, Connect and Help item text  */
$navpage-nav-selected-bg: Olive  /*  #4B545F - Selected Navigator and Connect tab background */
$navpage-nav-selected-color: OrangeRed  /*  #ffffff - Active Navigator and Connect tab icons  */
$navpage-nav-unselected-color: Orange  /*  #bec1c6 - Inactive Navigator and Connect tab icons  */
$navpage-nav-border: Magenta  /*  #ddd - Global Search, Navigator and Connect search box outlines + search box filter icons  */
$nav-hr-color: YellowGreen  /* #303a46 - Separator modules without a label + Vertical separator line between main frame and Navigator/Sidebars  */
$nav-highlight-bar-active: Red  /*  #278efc - Highlight line under active Navigator/Connect tabs + selected Connect, Help or Settings icon + number of Connect messages dot  */
$nav-highlight-bar-inactive: PaleGoldenRod  /*  #828890 - Highlight line under inactive Navigator/Connect tabs  */


/* Search text */
$search-text-color: LightGreen  /*  #e7e9eb - Search text + clear search text icons + Navigator bar filter icon when minimized  */


$connect-latest-message: Violet  /*  #cfd4d8 - no idea, not able to see it  */

 

 

Just like the previous test Themes, it is not meant for actual use, but to help point out what properties affect what controls.

 

I used the default values from the "Default CSS styles for UI16" section from the Default CSS styles article on the docs site to build the Theme.  Here is a list of the individual properties with screenshots to show the affected controls/areas, which appear in yellow.

 

 

$navpage-header-bg - #303a46

  • Banner frame background

 

 

$navpage-header-color - #ffffff

  • Banner frame title text
  • Domain picker icon
  • Global Search icon

 

 

$navpage-header-button-color (unknown default, not listed in the Default CSS styles article)

  • Logged-in user name text
  • Connect, Help and Settings icons

 

 

$navpage-header-divider-color - #455464

  • Banner frame separator line

 

 

$navpage-button-color - #ffffff

  • Update Set and Application icons
  • Minimize Navigator and Edit Favorites icons
  • Create a New Conversation, Open Connect standalone interface and Close Connect Sidebar icons

 

 

$navpage-button-color-hover - #7ec24F

  • Update Set, Application, Global Search, Connect, Help and Settings icons when cursor is over the controls (only the Global Search icon is highlighted in the first screenshot below but the others will highlight when the cursor is over them)
  • Clear search text icon when cursor is over the control in Navigator and Connect sidebar
  • Navigator bar icons when clicked (some browsers [e.g. Chrome] only remove the highlight after cursor is clicked elsewhere)

 

 

$navpage-nav-bg - #303a46

  • Navigator, Connect and Help Sidebar header and footers
  • Unselected Navigator and Connect tabs background
  • History time separator background

 

 

 

$navpage-nav-bg-sub - #455464

  • Navigator, Connect and Help Sidebar backgrounds
  • Background for Applications, Favorites and History entries
  • Selected icon when editing a Favorite

 

 

$nav-highlight-main - #3D4853

  • Module/Favorite (not in Safari)/History/Help item when clicked (each browser has its own quirks with this one - Safari only shows while clicking the item, others will keep the highlight a second or so, and some keep the Help item highlighted until the cursor is clicked elsewhere)
  • Selected Connect item (remains highlighted until another is selected or another record's chat window is selected or the record's chat window is closed)

        

   

 

 

$subnav-background-color - #455464

  • Module background

 

 

$navpage-nav-color-sub - #bec1c6

  • Module text
  • Edit Module and Add To Favorites icons

 

 

 

$navpage-nav-app-text - #cfd4d8

  • Application title text
  • Edit Application and Add to Favorites icons
  • "Loading..." Navigator message
  • Favorites text
  • Delete Favorite icon
  • History time separator text
  • History items text
  • Connect message text
  • Connect informational text
  • Help sidebar title and items text

        

        

 

 

$navpage-nav-app-text-hover (unknown default, not listed in the Default CSS styles article)

  • Module text, Edit Module and Add To Favorites icons when Module is selected/clicked
  • Favorite text and Delete Favorite icon when Favorite is selected/clicked
  • History text, Connect message and Help item text when selected/clicked
  • First Module that matches a Navigator search

 

 

$navpage-nav-selected-bg - #4b545F

  • Active Navigator tab background (Apps, Favorites or History)
  • Active Connect tab background (Chat or Support)

 

 

$navpage-nav-selected-color - #ffffff

  • Active Navigator tab icon (Apps, Favorites or History)
  • Active Connect tab icon (Chat or Support)

 

 

$navpage-nav-unselected-color - #bec1c6

  • Inactive Navigator tab icons (Apps, Favorites or History)
  • Inactive Connect tab icons (Chat or Support)

 

 

$nav-highlight-bar-active - #278efc

  • Highlight line under active Navigator tab (Apps, Favorites or History)
  • Highlight line under active Connect tab (Chat or Support)
  • Selected Connect, Help or Settings icon (only the Connect icon is highlighted in the screenshot below but the others will highlight when clicked/selected)
  • Number of Connect messages dot
  • Outline of logged-in user control when selected

   

   

 

 

$nav-highlight-bar-inactive - #828890

  • Line under inactive Navigator tabs
  • Line under inactive Connect tabs

 

$nav-hr-color - #303a46

  • Separator modules without a label
  • Vertical separator line between main frame and Navigator/Sidebars

 

 

$navpage-nav-border - #dddddd

  • Global Search, Navigator and Connect search box outlines
  • Navigator and Connect search box filter icons
  • Outline of logged-in user control when selecting a drop-down menu item

 

 

$search-text-color - #e7e9eb

  • Global Search, Navigator and Connect search text
  • Clear search text icon in Navigator and Connect search boxes
  • Navigator bar filter icon when minimized

 

 

 

Updates

I'll try to keep this post updated with anything new that I find.  Please let me know if I've missed anything, or if something is incorrect.  Thanks in advance.

 

 

Updated Sunday, December 10, 2017

  • added "First Module that matches a Navigator search" to the "$navpage-nav-app-text-hover" property

*** Please Like and/or tag responses as being Correct.
And don't be shy about tagging reponses as Helpful if they were, even if it was not a response to one of your own questions ***

A customer recently notified me that they were missing a lot of important updates to tickets.  The updates were expected to be delivered via an email integration.

Checking sys_email, I noticed a ton of new received-ignored messages with failure messages like this...

The error string didn't provide any help, so I dug into the headers.  BAM!  All the failures had X-ServiceNow-Spam flags in the headers. 

That's critical info because of this default sys_property:

What troubled me is why this suddenly became a problem.  I managed to find KB0549426 which stated...
"Note that as of 6/29/2017, SPF checks now factor more heavily into a mail's spam score.  In order to be flagged as spam, a message must have an aggregate score of 6.2 or higher.  A soft SPF failure will add 6.0 to the score, whereas a hard SPF failure will add 7.0 to the score (immediately flagging it as spam).  It is recommended to check and ensure that your company's SPF records are correct and up-to-date, or some messages may be inadvertently marked as spam."

 

So that explains why inbound email actions have been so unreliable for the past couple weeks.  I recommend everyone check their sys_email logs for anything with "received-ignored" state.  You could be in my customer's position with a *TON* of missing data.

 

POSSIBLE RESOLULTIONS

- So the KB article instructs you to "update the SPF records", but this is coming from another ServiceNow instance.  Does this mean all SN to SN mail integrations are now suspect?

- Remove X-ServiceNow-Spam-Flag:YES from the "Ignore mail with these headers" sys_property.

Shahid Shah

Free Service Portal Widget

Posted by Shahid Shah Employee Jul 13, 2017

There are many people freely sharing Service Portal widgets on the ServiceNow Share. If you haven't done it yet, stop trying to code your next widget and check if one already exists for you.

 

As I have much love for the product and the community, I wanted to get in on the act too and share the love. So I'm excited to share with you the Search Page with Assistance widget, which was created in response to this discussion. Yup, I had a Barney Stinson moment ("Challenge accepted!").

 

In short, this widget is a take on the OOB widget called Search Page, with one missing element... the "Did you mean?" suggestions. (Would it be naughty to say this is how the widget should've been?)

 

Screen Shot 2017-07-13 at 19.08.27.png

 

Just make sure you already have the behaviour enabled by setting the glide.ts.dym.enable_spell_correct and glide.ts.dym.enable_chain_suggest properties to true, then toggle the options for the widget.

 

Feel free to do what you want with it: use it, rip/change the code, or even shred it. It's yours now.

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."

In this episode, Silas Smith and Bryan Barnard discuss Web Services, including content from Istanbul, Jakarta, and Knowledge 17.


volume_icon.png

Listen

 

 

Subscribe

 

to iTunes

 

This episode covers:

  • HTTP logging in Istanbul
  • Knowledge 17 and the rise of the internet of things (IoT)
  • Server name indication (SNI) in Jakarta
  • Web Services resources

 

For more information on Web Services, see:

 

Your feedback helps us serve you better! Did you find this podcast helpful? Leave us a comment to tell us why or why not.

 

LISTEN BELOW

 

 

To catch clips behind the scenes with our podcast guests, and find out what topics we'll be covering next before they are posted, follow @NOWsupport on Twitter. You can also search Twitter using the hashtag #SNtechbytes for all previous podcasts, video clips and pictures.

Filter Blog

By date: By tag: