Design Archives - ServiceNow Guru

Exporting Records to CSV Using ServiceNow Flow Designer

Donte Hooker — Tue, 05 Nov 2024 10:00:22 +0000

Exporting data from ServiceNow is a common requirement for many organizations, whether for reporting, data analysis, or integration with other systems. One of the powerful features of ServiceNow is the Flow Designer, which allows you to automate processes without writing code. In this post, we will walk through how to create a Flow in ServiceNow that exports records to a CSV file.

Prerequisites

Before we begin, ensure you have the following:

– Admin access to ServiceNow: You’ll need the necessary permissions to create and manage Flows.
– Knowledge of Flow Designer: Basic understanding of how Flow Designer works.
– Records to Export: Identify the records or the table you want to export.

Step 1: Identify the Records to Export

First, determine the table from which you want to export records. For example, you might want to export incident records, change requests, or custom records. Let’s say you want to export incident records that are in the “Resolved” state.

Step 2: Create a New Flow

1. Navigate to Flow Designer: Go to the application navigator and type `Flow Designer`. Click on it to open the Flow Designer interface.

2. Create a New Flow:
– Click on `+ New` to create a new Flow.
– Give your Flow a meaningful name, such as “Export Resolved Incidents to CSV.”

Step 3: Add a Trigger

The Flow needs a trigger to start the process. Depending on your requirement, you can choose different types of triggers.

– Scheduled Trigger: This allows you to export records at regular intervals (e.g., daily, weekly).
– Click on `+ Add Trigger`.
– Select `Scheduled` as the trigger type.
– Configure the schedule as per your requirement, for instance, daily at midnight.

Step 4: Add an Action to Fetch Records

Now, you need to add an action to fetch the records that you want to export.

1. Add Action:
– Click on `+ Add Action` under the trigger.
– Choose `ServiceNow Core` as the action category.
– Select `Look Up Records` as the action.

2. Configure the Action:
– Choose the table from which you want to fetch records, e.g., `Incident [incident]`.
– Define the conditions to filter the records. For example, `State is Resolved`.
– Store the output in a variable, for instance, `incident_records`.

Step 5: Add an Action to Create CSV Content

To create a CSV file, you need to convert the fetched records into a CSV format.

1. Add Action:
– Click on `+` below the previous action.
– Choose `Script` as the action category.
– Select `Run Script`.

2. Write the Script:
– In the script editor, write a script that converts the records into CSV format. Here’s a sample script:

*javascript*
(function execute(inputs, outputs) {
var records = inputs.incident_records;
var csvContent = “Number,Short Description,State\n”;

records.forEach(function(record) {
csvContent += record.number + ‘,’ + record.short_description.replace(/,/g, ”) + ‘,’ + record.state + ‘\n’;
});

outputs.csvContent = csvContent;
})(inputs, outputs);

– This script assumes that you want to export the incident number, short description, and state.

Step 6: Add an Action to Save the CSV File

The next step is to save the CSV content as a file in ServiceNow.

1. Add Action:
– Click on `+` below the previous action.
– Choose `ServiceNow Core`.
– Select `Create Record`.

2. Configure the Action:
– Select `Attachment [sys_attachment]` as the table.
– Set the `Table Name` to the table where you want to attach the file, e.g., `Incident [incident]`.
– Provide a name for the file, e.g., `Resolved_Incidents.csv`.
– Set the `Content` field to the `csvContent` variable from the previous script.

Step 7: Test the Flow

Before running the Flow in production, it’s crucial to test it.

1. **Save the Flow**: Ensure all steps are configured correctly and save the Flow.

2. **Test the Flow**: Click on `Test` to manually trigger the Flow and verify that it works as expected.

Step 8: Activate the Flow

Once you have tested the Flow and confirmed it works correctly, activate it by toggling the Flow status to `Active`.

Conclusion

With this Flow in place, you now have an automated process to export records from ServiceNow to a CSV file. This Flow can be further customized to meet your specific needs, such as exporting different fields, filtering records based on more complex criteria, or integrating the export process with other workflows.

Using ServiceNow’s Flow Designer to export records is a powerful way to automate data handling, saving time and reducing manual effort. Give it a try and see how it can streamline your workflows!

The post Exporting Records to CSV Using ServiceNow Flow Designer appeared first on ServiceNow Guru.

The C4 model for ServiceNow Solution Design and Documentation

Martin Ivanov — Mon, 17 Jun 2024 16:24:25 +0000

Having been in the software development space for over seven years, I have observed multiple issues occurring in almost every project, regardless of industry, company size, type of implementation, tools, etc. You might have guessed already: I am talking about documentation, or rather the lack thereof.

Problem definition

Even when documentation is present, it is often written in a freeform manner, comprising a mixture of screenshots, URLs, and explanations. Each stream lead or architect has their own understanding of best practices and documentation layout, which, especially in large and complex implementations, results in many different documents that are inconsistently structured and formatted.

These documents might be readable during the implementation phase or shortly thereafter, but if a new joiner needs to quickly catch up, they will have a really hard time—trust me, I’ve been there and done that.

The list of issues with freeform documentation goes on and on. Sometimes an executive or an enterprise architect needs to quickly check something and make a decision based on it. Instead, they must read through the aforementioned documents and spend a lot of time trying to find that one piece of information. And we all know how frustrated they become when their most precious resource is wasted. We all do.

Here comes the solution: The C4 model.

Quick overview of the C4 model

The C4 model was created by the Software Architect Simon Brown between 2006 and 2011, but it became popular after the launch of an official website and an article in 2018.

According to the official website, “The C4 model was created as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing codebase. It’s a way to create maps of your code, at various levels of detail, in the same way you would use something like Google Maps to zoom in and out of an area you are interested in.”

Further clarified in Wikipedia, “The C4 model documents the architecture of a software system, by showing multiple points of view that explain the decomposition of a system into containers and components, the relationship between these elements, and, where appropriate, the relation with its users.

The viewpoints are organized according to their hierarchical level:

Context diagrams (level 1): show the system in scope and its relationship with users and other systems;
Container diagrams (level 2): decompose a system into interrelated containers. A container represents an application or a data store;
Component diagrams (level 3): decompose containers into interrelated components, and relate the components to other containers or other systems;
Code diagrams (level 4): provide additional details about the design of the architectural elements that can be mapped to code. The C4 model relies at this level on existing notations such as Unified Modelling Language (UML), Entity Relation Diagrams (ERD)or diagrams generated by Integrated Development Environments (IDE).

For level 1 to 3, the C4 model uses 5 basic diagramming elements: persons, software systems, containers, components and relationships. The technique is not prescriptive for the layout, shape, color and style of these elements. Instead, the C4 model recommends using simple diagrams based on nested boxes in order to facilitate interactive collaborative drawing. The technique also promotes good modelling practices such as providing a title and legend on every diagram, and clear unambiguous labelling in order to facilitate the understanding by the intended audience.”

Different levels of zoom allow you to tell different stories to different audiences. (Source: c4model.com)

The C4 model for ServiceNow Solution Architecture design and documentation

I’ve been using the C4 model for documenting ServiceNow solutions ever since I joined the architecture team I am currently working on. This kind of documentation is standard practice on every project we work on, along with a few others.

In the following paragraphs, I will go through each of the four levels with a simple example of an integration between ServiceNow and an external system, feeding foundation data into the platform.

Here is a helicopter view of the whole diagram. Do not be frustrated if you don’t understand it the first time. Bear with me.

Helicopter view of an example integration, documented according to the C4 model

Let’s break it down

Level 1: System Context Diagram

As stated previously, the goal of the System Context Diagram is to document the main system and its interactions with users and other systems. In our case, this is ServiceNow, which interacts with BMC Remedy, feeding foundation data. The main persona here is the Foundation Data Admin on the Remedy side, who is responsible for the data’s completeness and correctness.

Zoom-in: System Context Diagram

Level 2: Container Diagram

The documentation states that this level aims to decompose a system into interrelated containers. A container represents an application or a data store.

In the current example, we can easily see that the foundation data import is implemented through the system scheduler, which executes data imports via REST API calls to the external system, using a technical account for authentication. The data is transformed by Transform Maps and stored in the database.

Zoom-in: Container Diagram

Level 3: Component Diagram

Zooming in to the Component layer, we try to decompose containers into interrelated components and relate the components to other containers or systems.

We’ve mentioned the system scheduler and the data source at the Container level, but here at the Component layer, we can get further information about the specific scheduled job, its name and interval, the name of the data source, as well as more specific details about the REST message and the service account.

Zoom-in: Component Diagram

Level 4: Code

The goal of this layer is to provide additional details about the design of the architectural elements that can be mapped to code. In most cases, this can be skipped or partially documented for the sake of simplicity. In our practice, we try to document at least the custom code that we have implemented as part of the project.

Looking back at my simple example, at the Code level, we can see a breakdown of the Data Source code and the Script Include that it references.

Zoom-in: Code

Benefits

While it might look a bit confusing when seen for the first time, an implementation documented according to the C4 model has multiple benefits.

First and foremost, it is documentation readable by all personas – executives like CIOs and COOs, Enterprise and Solution Architects, Business Process Consultants, and of course, implementers and developers. A picture is worth a thousand words, right?

When this type of documentation becomes a standard practice, it becomes really easy to onboard new people to a project or communicate design decisions with various stakeholders because they already know how to read it.

On the other hand, documenting every implementation with the same standard approach quickly builds up a library of reusable reference architectures that can be used with just a few tweaks or as communication/demonstration material during the early project phases while decisions are being made.

Last but not least, frameworks like Mermaid.js allow for diagrams to be presented as code, giving us a chance to store these in centralized repositories. Furthermore, we can use AI to analyze them and help us continuously improve our solution architecture.

Recap

The C4 model, an “abstraction-first” approach to diagramming software architecture, can be applied for the design and documentation of ServiceNow solutions, introducing a new standard approach for documentation with multiple benefits for both customers and implementation partners.

The post The C4 model for ServiceNow Solution Design and Documentation appeared first on ServiceNow Guru.