Skip navigation

As companies are moving the existing legacy application to the cloud and adopt a mobile and social first approach; users are becoming less tolerant of antique interfaces, stand alone applications that lack proper integration, and data in various silos. Today’s companies need modern and easy to use apps that are accessible from any device, consolidated data, easy integration with back office systems, and the ability to innovate & adapt.

 

As part of the journey to modernize the application portfolio, many companies are looking to replace Domino Lotus Notes (DLN)  applications.  These applications range in variety, complexity, and functionality.  Many DLN applications are task and workflow based, which make them ideal candidates to migrate onto the ServcieNow Platform.  In this paper, we describe an approach to migrate your DLN applications onto the ServiceNow Platform.

 

Based on our experience from a large number of DLN to Servicenow Platform migrations, we typically see four phases to migrating your DLN application:

 

Phase 1: Determine Complexity

In this phase you will be working with the process owner of this app.  They should be able to take you through the workflow and use cases for this app.  Don’t worry about solving the technical details at this point, but get the requirements flushed out, and leverage the expertise of the process owner to take notes about where this app can improve when migrated to ServiceNow.

 

I often get asked at this phase – “Does ServiceNow have a tool that lets me migrate my DLN app into ServiceNow automatically?”  There is no migration tool, but what I have found is that most people want to use this opportunity to readdress the implementation of the previously written DLN app, and fix issues with their implementation (not migrate over same problems). 

 

It is at this phase we break down an existing DLN application and really understand what needs to be migrated.  Use this opportunity to rethink how things should be implemented.  Avoid over-engineering and unwanted functionality (process, data, integrations, etc.) to the new Platform. Take note about fields on our forms that are not used, overloaded, or the wrong field type; making our workflow more difficult than it should.

 

I normally like to collect answers to the following questions (thank you to my colleague Frank Schuster for sharing these questions):

  • What is the functional app description?
  • Who is the business owner of the app?
  • What is the business criticality of the app (on a scale from 1-5, 5 being very critical)?
  • What was the usage of the app in the past 3 months?
  • How many Notes databases are required for this app?
  • Are there integrations or messaging involved with this app?  Does the app use Sametime for messaging?
  • What is the current size of the database?
  • What is the number of documents in the database?
  • Does the app use ACL and what does that security structure look like? Who has what roles?
  • Does the app need to be optimized for mobile?
  • Does the app generate Outlook calendar invites?
  • Do we need to migrate the existing data into ServiceNow?

 

Phase 2: Plan for Success

You have a few options to solve your app requirements on the Now Platform.

  1. If things are pretty simple, in terms of data model and workflow, then a catalog item may be the best approach. Catalog items are services that are available to order from a service catalog, and use the out-of-box service catalog request data model. Administrators and catalog administrators can define catalog items, with details such as formatted descriptions, workflow, etc. There is no hard and fast rule here, but it is generally a good idea to keep it simple and clean, and included in the appropriate ServiceNow scope. 
  2. You can also define your own data model, not using the service catalog request item table, and keep things nicely contained within one functional ServiceNow application.  These simple data models are easy DLN migrations, and can be represented similarly to the catalog item (within a service catalog and with their own custom workflow).  The main difference between this type of implementation and a catalog item implementation is usually around licensing.
  3. Ultimately, if what you need to convert has a pretty complex data model, workflow, security, integrations, or other business logic, then you should probably do the implementation as a separate application on the Now Platform.

 

As a best practice you should not create a one to one application in ServiceNow for every DLN application.  In ServiceNow, you have the ablity to create application scopes that represent functional groups.  A functional group is defined in terms of the service you are offering, meaning that a single application may contain several DLN applications in one ServiceNow application scope.  For example, if you have several DLN apps that are used for invoicing, you may want to create one ServiceNow application for invoicing, and combine the functionality of those DLN apps into one Servicenow application scope.

 

Extending Task tables

Another big question to ask at this point is how to extend your data model from the ServiceNow Task table.  Task is one of the core tables provided with Servicenow Platform; it provides a series of standard fields used on each of the tables that extend it, such as the Incident and Problem tables. In addition, any table which extends task can take advantage of task-specific functionality for driving tasks.

 

Once again, we do not have to talk about the implementation details here. We do need to find out if we should treat and use the functionality that ServiceNow gives us around extending the task table.  There is no changing our mind once the table is created, without rebuilding the entire table.  I generally like to introduce some of the features of extending Task, in order to determine if we want to introduce this in our DLN app migration.  There are several out-of-box features you get if your data model extends Task, but there also comes a lot of extra metadata you may not really need. A previous blog post talks about extending the task table here:  What you get by extending the Task table .  If your DLN requires SLAs or Visual Task Boards, then the decision is easy - extend Task.  Look at the provided link and make that determination at this stage in the process.

 

I also like to start mapping parts of DLN to the appropriate ServiceNow application file as we will migrate this DLN app to ServiceNow.  It is much easier to break down functional requirements if we have gone through this exercise up front. We can also identify any gaps in product features at this point, and make the decision if ServiceNow is the right tool for this particular DLN application.  I usually like to categorize my application components into three main categories:

  1. Data Model
  2. Display
  3. Code

 

Data model

The data model from DLN will include tables, fields, files, and data relationships.  This maps pretty nicely into ServiceNow as a table, with the appropriate fields and security.

 

Display

The User Interface from DLN will include forms, views, navigators, and web pages, and these will map into UI Pages, Catalog Items, Portals, Process State Flows, Dashboards, Reports, and Related List in ServiceNow.

 

Code

The code from DLN will include formulas, LotusScript, Java, JavaScript, and other API calls. This will map into business rules, workflow, script includes, and events within ServiceNow.  All of the coding for converting these DLN files will be done in JavaScript on the ServiceNow Platform.  With the exception of Web Pages (which use HTML, CSS, etc) all of the implementation in ServiceNow is done in JavaScript.

 

Phase 3: Build and Test for Quality

Once you know what needs to be built, and we have a migration plan, the implementation isn’t too hard to do. I usually start building the data model first.  Most of the functionality in ServiceNow is data driven.  What I mean by this, is that once we create the right table structure ServiceNow will autogenerate APIs, List views, and Forms based on the data model.  This can all be done with no code in the ServiceNow Platform, saving quite a bit of development time.

 

After all of the tables are created, I start to tweak the out-of-box List and Form views of our newly created table.  Remember these forms are autogenerated by ServiceNow.  Once again we can do this without code.  I usually like to insert some sample data and create some reports and dashboards in this phase as well as use our out-of-box Service Portal if a more modern single page application is necessary.

 

Lastly I tackle the business logic.  This is where I build out the workflow and reimplement the coding details given from the DLN side of things. Understanding the process at this point is imperative.  Do you need approvals for a particular request? Do you calculate data when a particular database trigger is fired?  Do we need to implement a particular integration with an external system?  All those requirements are addressed in this phase.

 

Ultimately, you do not have to follow these steps exactly. You may find yourself bouncing around these steps, but as a best practice it is important to test frequently along the way.  What I mean is that you implement a functional requirement and test, then implement another requirement then test.  These tests are not a full test, but small functional test based on the feature you currently implement.  Once you feel your application is in a good state, then you can publish to a Test instance of ServiceNow and do a full end to end test with real production data, etc.  Depending on the complexity of app you may have multiple deployments of an app (resulting in more than one version before it is pushed to production).  It is recommended that you use GIT as a repo for this ServiceNow application, as it facilitates the management of these versions.  It is also a best practice to do all code changes and development on your ServiceNow development instance and not on your test/QA or production instances.

 

Phase 4: Deploy into Production

At this point in the migration we are ready to get our application into the hands of our customers (internal or external).  As a best practice I like to deploy frequently.  Do not be afraid to get your application into production and start getting feedback from your user base.  ServiceNow has a feature for publishing applications to a private repository for your company domain.  It is through this publishing your other instances will have access to the install or update your newly created app.  The length of time to convert a DLN app depends on the complexity of what we are converting.  You may find yourself publishing multiple applications a day and some that may take a week.

 

This paper is only the beginning of what you can do once you convert an app from DLN into ServiceNow.  There are many features within the ServiceNow Platform we did not get into, but can be utilized to enhance your DLN application from then to NOW!

 

Feel free to contact me at: chris.maloy@servicenow.com

The Treasure hunt is back on. Earlier this year we had the hidden diamonds of Jakarta(LINK) and now it's time for the lost treasure of Kingston.

 

For those who find the hidden diamonds of Jakarta, my main thoughts here is to highlight the new features in Kingston that might not have gotten the same amount of star power as for example Flow Designer or the entrance of AI.

Before I start, I must say thou that my personal favorite is the Flow designer. I really like it and I think it can really be a game changer when it comes to slim your process, have better performance, less coding and the potential of re-usability within the designer is huge.

 

AI is of course also really cool, but in Kingston it's still in it's cradle, but I think it will unleech it's true self (hopefully we dont all die ) in London.

 

So, back to the lost treasures. First I want to mention two things that ServiceNow has buried so deep in Kingston, that those functionalities is long gone and I don't have any treasure maps to find them

 

  • UI11: I'm guessing many of you don't even know about this. I myself started my journey on Eureka where UI14 came, so I haven't even used it myself. Until Kingston, you could have lived in past and still using UI11, but in Kingston, it's gone.
  • Next thing that also has vanished is the ability to hold "Shift" and hover over the "i" in the list meny to get a popup window with the record in edit mode.

 

Now for the fun part:

 

Service Catalog in Service Portal:

There coming a whole new bunch of widgets and other fun stuff. The Service Catalog gets whole bunch of loving and for example our beloved Order guide now gets support for attachments; even per item. And as you can see for the order guide, it reminds a lot of the view we got in the native UI.

 

You can read more about it here: https://docs.servicenow.com/bundle/kingston-release-notes/page/release-notes/it-service-management/service-catalog-rn.html

 

Automated Test Framework (ATF):

I haven't have have time to look deep into ATF as I want. But I can see that one things that I would really love if I used ATF, is the new feature to be able to rerun specific failed tests in a suite without need to rerun the whole suite.


You can read more about it here: https://docs.servicenow.com/bundle/kingston-release-notes/page/release-notes/servicenow-platform/automated-test-framework-rn.html

 

The CMDB SDK:

he CMDB SDK provides a set of Representational State Transfer (REST) application programming interfaces (APIs) that enable third-party applications to use the identification and reconciliation engine to create, read, and update configuration item (CI) records. Thus, eliminating duplicate CIs and improving overall CMDB data quality.

 

So hopefully this will lighten up the life the CMDB people when it comes to make sure there isn't duplicate Cis etc.

 

You can read more about that and more CMDB news here:

https://docs.servicenow.com/bundle/kingston-release-notes/page/release-notes/servicenow-platform/cmdb-rn.html

 

"Workspaces":

In Kingston we see a few of these workspaces (not sure of the official label). In my eyes there are the future and I bet in London these will have grown and taking over a lot more applications. If you want to see how it works, take for example a look at the Agile Board. (You need to activate the agile 2.0 plugin to get it).

 

You can read more about the agile board here: https://docs.servicenow.com/bundle/kingston-release-notes/page/release-notes/business-management/agile-development-rn.html

 

Software Asset Management (SDM):

In Kingston there will be OOB integration to handle your Office365 subscriptions. I think there is a lot of money for companies to be saved in all kind of licenses and Office365 sure is a place there has saving potential as well.

 

You can read more about it here: https://docs.servicenow.com/bundle/kingston-release-notes/page/release-notes/it-service-management/software-asset-management-rn.html

 

Performance Analytics:

Now you have the ability to use External Data sources to pull information from to your PA reports. Real simple and no data is saved in ServiceNow, only the scores is saved in ServiceNow.

 

You can read more about it here: https://docs.servicenow.com/bundle/kingston-performance-analytics-and-reporting/page/use/performance-analytics/concept/pa-external-data.html

 

Function fields:

A new field type has become reality in Kingston. With this field you can do let it show the result of a database function like for example add, concat or datediff. And by doing this here instead of a business rule, you should get a lot better performance. So together with the Flow designer, I think we will see a lot less use of business rules in the future than we have seen in the past.

 

You can read more about it here: https://docs.servicenow.com/bundle/kingston-release-notes/page/release-notes/servicenow-platform/platform-support-functions-rn.html

 

And for last,

 

Mobile App

The mobile app is really starting to evolve and now there is functionality for user to still be able to use the app even if they doesn't have an internet connection. I think this is a real nice feature and probably wanted by many.

You can read more about it here: https://docs.servicenow.com/bundle/kingston-service-management-for-the-enterprise/page/product/field-service-management/concept/mobile-interface-offline-support.html

Good luck on the treasure hunt!

 

 

//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

So, this time I my journey took me into the Service Portal and the widgets. This time I was looking at a knowledge article within the portal and wonder who I can make the picture bigger if I clicked on it. To be able to achieve that I took use of the functionality called Link function which you can see in the widget editor. I can easily say that I never used that before so I wasn't really sure how to use it and what it really was for.

I took a look at the documentation and what I could find out was that I used Link Function to directly manipulate the DOM (Link Docs). And this was pretty much what I was after. To manipulate the pictures in the articles so if I click on them, I would get a enlarged version.

 

I made a video here showing what I did and how I did it.

 

 

So grab a cup of coffee and enjoy.

//Göran

 

Symfoni Logo Color Box.jpgsn-community-mvp.png

//Göran

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

LDAP Integration allows ServiceNow instances communicating with Active Directory (AD). This integration facilitates customers in following:

 

  1. Importing Users/Groups/Roles from AD to ServiceNow instance
  2. Schedule this import so as to keep the data in sync with AD
  3. Authenticate users from AD when login ServiceNow instance

 

Hence, ServiceNow does not store LDAP user’s password as they are authenticated from the AD. ServiceNow instance resides on cloud/on premise and AD is installed on a different server.

 

At times, LDAP connection to AD fails due to whatever reason and no LDAP user is able to login. This leaves a big impact on business and cause a P1 incident. The root cause of this connection failure can be anything like a local network outage in customer area, incorrect LDAP connection attempts post cloning, LDAP credentials change on AD etc.

 

ServiceNow datacenter hosts excellent monitoring tools which polls LDAP test connections in customer instances and if a test connection fails, it generates an alert which in turn generates a high priority incident. Be it an issue on ServiceNow instance side or in a local network on customer side, the major impact is LDAP users cannot login and cannot work unless the issue is fixed.

 

In order to mitigate the impact, ServiceNow has introduced LDAP One Time Password feature from Istanbul release onwards.

 

What is LDAP One Time Password?

 

This is a new feature introduced with ServiceNow Istanbul release assisting LDAP users generating a temporary local password to login ServiceNow when LDAP Server is down. This is available and enabled Out of the Box and requires no plugin activation. It is controlled using below system properties:

 

  1. glide.ldap.onetime.password.enabled - It's a boolean property used to enable/disable this feature
  2. glide.authenticate.onetime.password.validity - It's an integer property indicating temporary password validity in minutes

 

How Does This Feature work?

 

OLD Situation: Login error message when LDAP is unreachable:

Old_Situation.png

Error message on screen: Your account is configured to use LDAP authentication, and we cannot currently connect to the LDAP server. Please contact your ServiceDesk to resolve this issue.

 

New Situation: Login error message when LDAP is unreachable

New_Situation.png

Here is the difference in error message: Your account is configured to use LDAP authentication, and we cannot currently connect to the LDAP server. Please contact your ServiceDesk to resolve this issue. To obtain a password for one-time login, click here. An email message containing the password will be sent to you.

 

User clicks the hyper link click here and platform sends a one-time password to user’s email address for next login as shown in below screen:

Temp_Pass_Gen.png

Behind The Interface In Platform:

  1. When user clicks on link click here, platform generates a one-time password in security_nonce table which can be used once and expires after used.
  2. By default this password is valid for 10 minutes but can be configured with system property glide.authenticate.onetime.password.validity.
  3. Post one-time password generation, platform generates an event password.online.
  4. This event in turn triggers email notification OneTimePasswordEmailNotification.

 

Troubleshooting Tips when user does not receive One Time Password:

  1. Login as an admin and check password.online in event logs.
  2. If event log is there, make sure notification OneTimePasswordEmailNotification is enabled in user profile.
  3. User profile has a valid email address.
  4. Open a Hi incident when you see steps 1 to 3 are OK and user still missing one-time password email.

 

This is a small feature but I find it a great enhancement as it brings down the impact of LDAP user login issue tremendously when LDAP Server is down and generates a big value for ServiceNow customers in terms of business continuity.

 

Resources:

LDAP Integration Setup

LDAP Integration FAQs

LDAP Integration Troubleshooting

Brgds, LK

PS: Hit Like, Helpful or Correct if I was able to assist you

While developing a scoped application, you may want to secure scoped applications against other applications. Securing application helps the author to have control of their application and prevents customers from interacting with any other artifacts without the author's knowledge. Below are the ways in which design time permissions on the scoped application can be granted or restricted.

 

3 ways to secure your application

  1. Application Access Setting
  2. Cross Scope Access
  3. Restrict Table Choices

 

In this post, I will show you how to utilize Cross Scope Access, Application access setting and Restrict Table Choices to secure your scoped apps against other applications. I'll give you examples of how to use Application Access Setting, Restrict Table Choices, Cross Scope Access to enable access, disable access, and track your scoped apps across the platform.

 

Application Access Setting

Application Access Setting is defined to specify what application artifacts are available to other custom applications in different application scopes. These permissions are in addition to the standard access controls (ACLs) that determine whether users can access data in the custom application.

 

  1. On your instance navigate to System Applications > Studio
  2. Click on open Studio tab.
  3. Click on the application and then select the tables whose application access setting needs to be modified. You will see the below image once you click on any table.

scoped application access.jpg

The Can read, Can write, Can update, and Can delete Application Access options, grant scripts from other application scopes the ability to perform database operations against the table records. In the default case, all application scope scripts can read the table’s records but cannot perform any other database operations.

 

 

"Allow configuration" restricts whether out-of-scope applications can create application files like Business rules, New fields, Client script and UI actions.

 

Restrict application on a scoped app

I can restrict other applications from doing any operation (Create, Read, Update, Delete, Web Service Interaction) on this scoped app by selecting the "Accessible from" value to “This application scope only.” Other application can only interact when the value is set to  "All application scopes.” Depending on the requirement and the use case, you can select all or either on this checkbox to grant permission for other applications.

 

For other artifacts like Script Include, access is granted or restricted depending on the value set on “Accessible from” field. This field defines whether a script is public or private.

 

Making a script public

A public script is a script available to all applications. To make a script public, set the "accessible from" field on the Script Include  to all application scopes. Any changes to a public script include must be done carefully to prevent breaking applications that depend on it.

 

Making a script private

A private script is a script which is specific to the application which it is defined.To make a script private and inaccessible from other applications, set the "Accessible from" field to This application scope only. This allows the script to be called only by code within the defined application scope and prevents code in other application scopes from accessing the script. By setting scripts to private, application developers can easily modify or refactor scripts in future versions since no other applications depend on it.

 

Example of creating a Record in a Group Table:

 

Application access settings are different on each OOTB tables. For example, the default Group table allows another application scope Web Service access and Read access. However, other permissions are restricted. If a script attempts to perform an operation that is not allowed, admin users see a message:

Execute operation on API 'GlideRecord.insert' from scope 'CSA' was denied. The application 'CSA' must declare a cross scope access privilege. Please contact the application author to update their privilege requests.

Evaluator: com.glide.script.fencing.CrossScopeAccessNotAllowedException: Access to GlideRecord.insert from scope x_13241_csa not allowed

In the above case, "Can Create" checkbox has to be set to true to be able to create the records in Group table.

 

 

Example of making a call to JSUtill from a scoped application:

 

In the below screenshot we can see JSUtil cannot be called from any other application as the accessible value OOTB is set to "This application scope only".

jsutill scoped app.jpg

In the above case, accessible from has to be changed to "All application scope" to ensure JSUtill works across applications.

 

Please be aware any changes made on global artifacts will be in the global update set.

 

Please work out with ServiceNow Certification Team in case you have modified the application access setting (Global or base system tables) and the app is intended to be submitted to store. We will approve or reject apps on the store based on the application use case. The same case applies to any modification made (Accessible From value) on base system artifacts like script include.

Cross Scope Access

Cross scope access allows administrators to manage out-of-scope access to application resources by creating a list of operations and runtime privileges that the application authorizes to run on the target instance. A cross scope is applicable only if the author of the app sets the Runtime access value to Tracking or Enforcing. This helps the author to have control on their application and prevents customers from interacting with any other artifacts without the author's knowledge once the app is downloaded on the target instances.

 

Cross-scope privileges can be granted for:

  • Table: Read, write, create, delete records
  • Script Include: Execute API
  • Scriptable (script objects): Execute API

 

Enabling Cross Scope Access

  1. On your instance navigate to System Applications > Studio
  2. Click on application i.e for ex : CSA ( This is the custom application I have created on my instance)

    create scope access.jpg

  3. Open the File menu and select the Settings menu item. The default value for the Runtime Access Tracking field is set to Tracking.

    scoped app tracking.jpg

 

  • None: All cross scope privileges are granted automatically at runtime.
  • Tracking: Allows application scripts to access resources from other applications. A record for the access is automatically inserted in the cross-scope access table with a Status value of Allowed. This is the default setting.
  • Enforcing: Allows application scripts to access resources from other applications only after an admin authorizes the access. A record is automatically added to the cross-scope access table with a Status value of Requested.

 

A custom application which have "runtime access " set to tracking will be changed to enforced automatically during app installation on the target instance.

 

During testing, application developers should run all of their application scripting logic to ensure the system creates any necessary cross-scope privilege records. After application publication, the system only allows runtime requests to run that have a valid cross-scope privilege record.

 

Example of across access scoped application:

 

Let’s assume I have a business rule on the custom table which creates a record on Incident table. To make this app work on other instance, I as an author should ensure that this script is at least once executed on my dev instance. You will see an entry in cross scope table as soon as this script is executed on dev instance before the app is published.

 

Here we are assuming Runtime Access Tracking is set to Enforcing.

var gr = new GlideRecord('incident');
gr.initialize();
gr.short_description = 'This is a test for CSA';
gr.insert();

 

When the script executes, ServiceNow checks to see if the cross-scope access between the CSA scope and the Global scope table is allowed. In this case, it is not because the Enforcing setting requires an admin to authorize the access. This is a snippet of the error from the System Log:

Security restricted: Execute operation on API 'GlideRecord.insert' from scope 'CSA' was denied. The application 'CSA' must declare a cross scope access privilege. Please contact the application author to update their privilege requests.

Evaluator: com.glide.script.fencing.CrossScopeAccessNotAllowedException: Access to GlideRecord.insert from scope x_13241_csa not allowed

 

  1. Open the Application Cross-Scope Access module by navigating to System Application> Application Cross-Scope Access
  2. Search for all records with a Status field value of Requested
  3. To grant access, an admin user must click the Open record icon to open the record for editing.
  4. Change the Status to Allowed then click the Update button.

access cross scope app.jpg

The above case is only when the author chose to set runtime access to enforcing. By default, runtime access is set to tracking on the application and at runtime, cross scope privilege records are automatically granted access.

 

 

Restrict Table Choices in a scoped application

To get to Restrict Table Choices, follow the same steps 1, 2 and 3 as mentioned in cross scope section above. Restrict Table Choices application sets limits on an application file configuration to only tables from the current application. This setting can be defined at each application level. By default, the checkbox is set to false. You can set the value to true depending on your app requirements.

 

Example of restricting table choices:

 

Let’s assume I have set Restrict table choice checkbox to true. In that case, we can only select tables which are in the same scope. This will be true for any artifact created in scoped app for ex: Client script, UI Policy Etc.

restrict table choices.jpg

 

We have successfully covered how Cross Access Tracking manages out-of-scope access to application resources, Application Access restricts database operations, and Restrict Table Choices application to limit application files configuration. Utilizing Cross Scope and Application Access Setting are key components of scoped applications and its success.

 

For additional help on this topic, see what other customers have asked:

cross scope privileges denied by table cross scope

Cross scope privilege issue in Scoped Application

access to api refused

Scoped apps - can I allow scripted read access to global scope without allowing creation of business rules, too?

- Pradeep Sharma (@sharma_pradeep)
ServiceNow

PS: Hit like, Helpful or Correct depending on the impact of the response

Filter Blog

By date: By tag: