ServiceNow | IRA Intellix Academy
10-minute course demo
English synthetic narration; captions included.

00:00 — Welcome to IRA

Welcome to IRA Intellix Academy. In this introductory lesson, we explore ServiceNow. Turn a request into a clear, trackable workflow. You will learn the basic ideas, follow a practical example, and try a small task yourself. Keep a notebook nearby. The example uses fictional information for learning. Our goal is to understand the decisions behind the work, so you can explain both what you would do and why.

00:30 — Work starts with a record

Enterprise service work is easier to coordinate when everyone can refer to a clear record. A record contains structured information about something that needs attention, such as a request or an incident. A table organises records of a particular kind. Fields hold individual values, such as requester, status, or assigned group. In ServiceNow, the exact forms and workflows depend on the organisation's configuration and available applications. Today we use a conceptual laptop-request example. Focus on the information, ownership, and decisions needed to complete the work. Understanding those ideas will help you make sense of the platform when you practise in an authorised environment.

01:30 — Request, incident, problem and change

Service management distinguishes several kinds of work. A service request asks for an agreed service or item, such as a new laptop. An incident involves an unplanned interruption or reduction in service quality. Problem management investigates causes of incidents, particularly where understanding the cause can help prevent recurrence. Change management coordinates modifications that may affect services. A broken laptop may create an incident, while asking for an additional laptop is usually a request. The organisation's definitions and processes matter, so confirm them before configuring automation. Routing every situation through the same workflow can create unnecessary approvals or omit controls that the work actually needs.

02:30 — The laptop-request scenario

Asha needs a standard laptop before her first working day. A useful request captures who needs it, the business reason, the required date, delivery details, and any approved specification. Collect only information relevant to fulfilment. Vague requests such as please arrange a laptop create extra messages because the fulfilment team must discover the missing details. At the same time, an unnecessarily long form discourages accurate completion. Design fields around the decision and delivery process. In our example, the manager and business reason are required for approval. The request record becomes the shared reference for the employee, approver, and fulfilment team.

03:30 — Route the approval correctly

Once submitted, the request follows the configured approval policy. Identify the correct approver from reliable organisational information rather than asking the requester to choose any convenient person. The approver needs enough context to make a decision. Approval should record who decided, when, and what they approved. A rejected or returned request should explain the next step. Approval does not mean the laptop has been delivered; it means the request may proceed to fulfilment. That distinction matters in reporting. Also plan what happens when the manager is unavailable. A defined escalation or delegation process is more reliable than allowing requests to remain indefinitely unattended.

04:30 — Assign and track fulfilment

After approval, fulfilment work needs clear ownership. The responsible team may allocate a device, apply the approved configuration, and arrange delivery. Each task should have an accountable owner and a meaningful status. Avoid a process where everyone can see the request but nobody is responsible for progressing it. When a dependency blocks work, record what is missing and who can resolve it. For example, device stock may be unavailable, or delivery details may be incomplete. Status updates should help the requester understand what is happening without revealing internal or sensitive information they do not need. The record should support coordination rather than becoming a collection of unexplained status changes.

05:30 — Verify completion before closing

Closing a request should correspond to a defined completion condition. In our example, confirm that the correct laptop was delivered, required preparation was completed, and the employee was informed. Update related records where the organisation's process requires it. A fulfilment task marked complete is not automatically proof that the employee received the device. Decide what evidence is appropriate and avoid collecting unnecessary personal information. If delivery fails, keep the request in the correct unresolved state and communicate the next step. Clear closure criteria improve reporting because completed requests represent a consistent outcome rather than whichever point an individual agent happened to choose.

06:30 — Access and useful reporting

Different participants need different views and permissions. A requester needs relevant updates on their own request. A fulfilment team needs the information required to complete assigned work. An approver needs the context for a decision. Broader administrative access should have a justified purpose. Reporting should also answer useful operational questions. How many requests are waiting? Which have been open longest? Where do delays occur? Define time measures consistently, including how waiting states are treated. A count of closed requests alone may hide long delays or incomplete fulfilment. Start with the decisions a team must make, then choose the reports and access rules that support them.

07:30 — Your workflow-design exercise

Design a laptop-request workflow on paper. Write five useful fields for the request, identify the approval owner, and list the fulfilment tasks. Add an exception path for a device that is out of stock. Explain what the requester should see while waiting and what evidence is needed before closure. Pause and check whether every step has an owner. Then choose one report that would help the service manager identify delays. This exercise prepares you to configure a workflow thoughtfully. The objective is a clear, traceable service process with appropriate access, useful communication, and an outcome that can be verified.

08:30 — Why choose IRA?

Why choose IRA Intellix Academy? Start with live, mentor-led learning, guided practice, and practical projects. Use each session to ask questions and understand the reasoning behind a solution. Practise the method yourself, keep your notes, and review your results. Learning Hub recordings let enrolled learners revisit published lessons. After completing your course lessons, career preparation can include mock interviews, resume preparation, and guidance for Naukri and LinkedIn profiles, depending on your selected package. Confirm the current course schedule and package inclusions with the academy before registering. Training supports your preparation; it does not guarantee employment or a particular salary. Bring curiosity, consistent practice, and a willingness to improve.

09:30 — Build your next chapter

You have completed this introductory demo for ServiceNow. Digital workflows make service work visible and repeatable. Your next step is to explain the example in your own words and complete the practice task. Visit www dot IRA Intellix dot com to explore the course, ask about the current batch, and register. IRA Intellix Academy. Learn a skill. Build your next chapter.