How to Create a One-Step Approval Workflow in ServiceNow (Beginner-Friendly Guide)

BillMartin · 13 hours ago

If you're new to ServiceNow and still getting comfortable with automation, a simple approval workflow is one of the best places to start. It is clear, practical, and tied directly to real requests in your company, like ordering a laptop or booking a flight that needs a manager's review.

In this guide, you walk through a complete example of a one-step approval workflow for incidents in ServiceNow. You see how a request starts in the Service Catalog, how it turns into a task for an approver, and how a basic flow updates the record once that approval happens. You also see how to test the whole thing in a safe developer environment.

Why Approval Workflows Matter in ServiceNow

Every approval workflow starts with a request. Someone asks for something that has a cost, a risk, or some kind of impact, and someone else has to review it.

Think of common cases:

You request a laptop that has a clear financial value.
You ask for a flight that needs budget approval.
You raise an incident that might need a supervisor to review.

ServiceNow lets you turn this simple pattern into an automated flow. At a basic level, a one-step approval workflow has three core parts:

Request: The starting point, usually a form in the Service Catalog.
Approval task: A task is assigned to an approver, with notifications sent by email, mobile, or portal.
End of process: After the approver responds, the flow finishes its work, such as updating the record.

Your company’s governance structure decides who can request and who can approve. In many cases, the requester is an employee, and the approver is their manager or a named owner.

If you are a beginner in tech or completely new to ServiceNow, this kind of one-step process is a great way to build your confidence with workflows.

Setting Up Your ServiceNow Developer Environment

Before you build anything serious, you need a safe place to try things, break things, and fix them again. That is what the ServiceNow developer environment gives you.

You get:

Demo data you can use as examples.
Ready-made templates you can copy.
An instance you can reset or destroy without affecting real users.

The Personal Developer Environment, "this is so powerful because it will have your demo data" and you can treat it like a lab. You only need an email address to start, and you can create multiple developer instances if you like to keep different labs for different topics.

A simple way to think about it:

Register with your email on the ServiceNow developer site.
Request a personal developer instance.
Log in and explore the demo applications and Service Catalog.
Use this instance as your playground for forms, flows, and approvals.

Because this is not production, you can try ideas, make mistakes, and learn from them without stress.

(Suggested image: screenshot of the ServiceNow developer environment login screen with demo data visible.)

Exploring the Service Catalog and Record Producers

What the Service Catalog Is

The Service Catalog is where you present services and requests to your users. In simple terms, everyone who works with your company is a client of some service, and the catalog is their menu.

Inside the catalog, you might see things like:

Report an issue.
Request an LDAP server.
Register a business application.
Create Incident (the example used in this walkthrough).

Since ServiceNow started as an ITIL platform, many of the out-of-the-box items are IT focused. You might also see extra items if you installed other apps, like enterprise architecture.

Each of these catalog items can be backed by a record producer, which is the key piece for your approval flow.

How a Record Producer Works

A record producer is a feature in ServiceNow that lets you create a specific kind of record through a simple request form. It acts like a bridge between the Service Catalog and a target table.

In the example used here, you:

Open the "Create Incident" record producer in the platform.
See the core components:
- Form attributes and configuration.
- A script pane.
- A set of variables (in this case, four variables).
- Embedded search results that appear as you type.
Notice that this producer is linked to the incident table.

To see how a requester would use it, you move to the Service Portal. On the portal side:

You act as a client, not a builder.
You search for the same "Create Incident" item.
You get a simple form where you might enter something like:
- Short description: "Hi"
- Description: "Email is not working"

As you type, you see the AI Assist feature start to help with suggestions. Because the form is configurable, you can later add more fields and parameters based on what your process needs.

Copying the Record Producer for Your Own Use

A smart way to learn without breaking anything is to copy an existing item. ServiceNow gives you a "Copy" option on the record producer.

In this example, you:

Open "Create Incident" in the platform.
Use the copy function so you get "Copy of Create Incident".
Save the copy.

Once you save it, ServiceNow publishes it, and it becomes visible in the portal. When you go back to the portal home page and search, you now see "Copy of Create Incident" as a new option.

That copy still points to the same incident table, which is exactly what you want for this simple one-step approval workflow.

(Suggested images: original incident producer form, copied form with new name, search results in the portal for both items.)

What Happens When You Have No Workflow

Before you wire in approvals, it helps to see what happens by default.

Using your copied record producer, you:

Go to the Service Portal.
Open "Copy of Create Incident".
Fill out the form and submit it.

Behind the scenes, ServiceNow creates an incident record. If you then go back to the main interface and open the list view for incidents by going to incident.list in the URL, you see your newly created incident.

Right now:

Some fields may be empty or not fully populated.
There is no approval step.
The incident just exists in its normal lifecycle.

ServiceNow incidents have states such as:

In progress
On hold
Resolved
In review
For approval

Without a workflow engine attached, you are not adding tasks, notifications, or approvals. You are only creating records.

Here is a quick comparison of behavior:

Aspect	Without workflow	With one-step approval
Record creation	Incident is created from the portal form	Incident is created and also sent for approval
Approval task	None	Approval task created for a chosen user or group
Notifications	Only base system behavior	Approval notifications sent via email, mobile, or portal
Field updates	Manual updates only	Flow can update fields, such as description
Traceability of approval	Not tracked in a structured way	Approval state and actions tracked in the flow

To get the richer behavior on the right side of the table, you use ServiceNow’s workflow engine through Flow Designer and related tools.

Building Your One-Step Approval Workflow in ServiceNow

You now have:

A copied incident record producer.
Incidents getting created from the portal.
A developer environment where you can test freely.

Next, you tie in the approval flow.

Opening the Workflow Tools

In the application picker, you go to Process Automation and open Workflow Studio. From there, you can open Flow Designer, which is the engine that runs your flows. For more advanced scenarios you would use playbooks, but for now a simple flow is enough.

You create a new flow, and by default it might suggest an analytics-related scope. That is not what you want for this example.

Naming and Scoping Your Flow

Scopes group related objects. You can think of a scope like a folder or umbrella for tables, flows, and other assets that belong together.

This is a short description of scope as a way of "organizing things". You choose the scope that matches the app or area you are working in rather than leaving it in a generic analytics scope.

Then you give your flow a meaningful name, such as:

"Copy Incident Workflow Approval"
"Incident One-Step Approval"

Good naming matters. It should reflect the purpose, for example "Flight Request Approval" if you are approving travel instead of incidents.

Connecting the Flow to the Incident Table

When you start building the flow, Flow Designer asks you to define how it should start.

You:

Choose a trigger like "When a record is created".
Select the Incident table as the record type.

Now the flow is tied to incidents that get created. On the right-hand side, you see the list of available fields and attributes for an incident record. You can use these later for conditions and updates.

To avoid running this flow for every record ever created, you add simple conditions. For this example, you can set:

Active is true.

That means your flow only runs for active incident records. In more complex cases, you might add conditions such as category, assignment group, or source.

Adding the Approval Action

Now you add the approval itself.

In the Flow Designer, add a new action.
Choose the Ask for Approval action.
On the right-hand side, you see the approval object that needs a record to work with.

Flow Designer shows "data pills" for the incident record that triggered the flow. You drag the record pill into the "Record" field of the approval action. That links the approval to the right incident.

Next, you configure:

Who can approve.
How many approvals you need.

For this simple flow, you choose Anyone approves. That means if any one of the listed users or groups approves, the approval step is marked as complete. You then add a specific approver. Since you are working as an admin in the lab, you can simply choose yourself as the approver.

Later, you can explore:

All users must approve.
A set percentage of approvers must approve.
Using groups instead of individual users.

Adding Logic for Approved Requests

Approval alone is not enough. You also want the system to react when the approval succeeds.

You:

Add a flow logic step, an If condition.
Set the condition to use the approval state from the approval action.
Check for when the approval state equals "approved".

ServiceNow already gives you these return values, so you can respond to success or failure. Inside the "If approved" branch, you add another action.

You choose:

Update record from the Core actions.

Again, you connect this action to the same incident record that triggered the flow. Then you pick a field to change. For this example, you can keep it very clear and simple:

Field: Description
New value: "Request has been approved"

This way, anyone who opens the incident later can see that the request passed through the approval flow.

Pointing it out that you learn this best by doing it many times. Tech is like math, you get better by practicing, not by memorizing. You make mistakes, fix them, and each time you understand a bit more.

A quick summary of the build steps:

Create a new flow in Flow Designer.
Choose the correct scope.
Set the trigger to "Record created" on the Incident table.
Add a condition, such as Active is true.
Add an "Ask for Approval" action and tie it to the incident record.
Set the rule to "Anyone approves" and choose an approver.
Add an If condition on the approval state being approved.
In the approved branch, add "Update record" to change the incident description.
Save your flow.

(Suggested image: Flow Designer canvas with trigger, approval action, and If branch clearly labeled.)

Testing and Experiencing the Workflow

Running a Test from Flow Designer

Flow Designer lets you test the flow right away. After saving, you:

Use the Test feature in Flow Designer.
Either pick an existing incident or create a new one through the portal.
Watch the flow execution details.

You see that the flow has started and then paused at the approval step. It shows a status like "Waiting for approval".

Approving from the Portal

To act as the approver, you:

Open a new browser tab.
Go to your Service Portal URL.
Look at the approvals section or notifications.

You see an approval card or widget created for your incident. This widget is provided by the platform, so you do not have to build that user interface from scratch.

From the widget, you:

Review the incident information.
Click Approve.

After you approve, the flow resumes. When you go back to the incident in the main interface, you see that the description has been updated to "Request has been approved", just as you defined in the flow.

You can then open the flow execution details again and confirm that the state is now complete, not waiting.

Always treat this as standard practice: always test your work. Each test gives you feedback that improves your understanding.

Key Components and Best Practices for Strong Workflows

The Core Elements of Any Workflow

Summarizing workflows in simple terms. You always come back to three main pieces:

Requester: The person and the form that starts the process.
Approval task: The work item sent to the approver to review and decide.
End of process: What happens after approval or rejection, such as status changes or field updates.

Behind these pieces is your governance model. That model covers how your company decides who can request, who can approve, and how those rules apply across departments.

Alongside governance is your operating model, which ties together:

People
Process
Technology (in this case, ServiceNow)

Your workflow design should match that operating model. If the business process is wrong or unclear, the most polished technical implementation will still not work well.

As Bill says, "A workflow is not difficult but you need to understand the components."

Practical Tips While You Learn

To get the most out of your time with ServiceNow workflows, keep these habits:

Practice in your developer environment, not in production.
Copy out-of-the-box templates instead of editing them directly.
Use clear, descriptive names for flows and record producers.
Test early and often, and check the flow execution details.
Work with multiple tabs or screens so you can switch between portal, lists, and Flow Designer.
Pay attention to data types when you drag fields into actions.
Use conditions to make sure your flows only run on the right records.

Conclusion

A one-step approval workflow in ServiceNow might look simple, but it teaches you many core skills at once. You create a request through a record producer, tie it to a table, trigger a flow, call an approval, and handle the result with clear updates.

Once you are comfortable with this path, you can extend it with more conditions, more steps, or more complex approval rules. You can also apply the same pattern to other kinds of requests, like hardware, access, or travel.

Keep practicing in your developer environment, treat mistakes as part of the learning process, and build up your own library of flows.