- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
an hour ago
Give me an elaborate view on Flow Designer. Important concepts on Flow Designer. And give me some real time examples with explanation.
Thanks in advance!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
an hour ago
Starting simple:
1. Auto assignment based on category and location. Incident is created, look up a routing table or the CI's support group, then set the assignment group. Good for getting used to data pills and understanding when to use Look Up Records versus Get Record.
2. Auto close resolved incidents. A scheduled flow that runs daily, finds incidents sitting in Resolved for more than 7 days, and closes them with a system comment. Covers scheduled triggers and looping over a record set.
3. Reopen on customer reply. Incident is Resolved, caller adds an additional comment within 5 days, flow moves it back to In Progress, reassigns to the previous assignee and sends a notification. Nice first use of Wait for Condition.
A bit more involved:
4. P1 major incident handling. Priority moves to 1, create a Major Incident record, notify the on call group, post a message to Teams or Slack, and start a 30 minute wait that escalates to the manager if nobody acknowledges. This one gives you parallel branches, timers and escalation logic in a single flow.
5. Multi level catalog approval. Manager approval first, then a second approval from the department head only if the cost crosses a threshold, then create catalog tasks in sequence. Build the approver logic as a subflow that takes the requested for user and the amount as inputs and returns the approver. Subflow inputs and outputs are the thing most people skip and then struggle with later.
6. Onboarding request with parallel tasks. One RITM creates IT asset, access provisioning and workspace tasks in parallel, and the RITM only closes when all three are done.
7. Change request routing based on risk. Evaluate risk and CI criticality, then send Standard changes to auto approve, Normal to CAB, and Emergency to a fast track group.
If you want something that will actually stand out on your CV:
8. Outbound integration with proper error handling. Incident is resolved, call an external system through an IntegrationHub REST step or a custom action, parse the response, and if the call fails, retry once and then log to a custom error table and notify the integration team. Handling the failure path is what separates a flow that works in a demo from one that survives production.
9. Inbound email to incident. Parse the subject and body, create or update the incident, then reply with the ticket number.
A few things worth paying attention to while you build these, because they come up again and again:
Run As and trigger security. Understand the difference between User who initiated session and System user. This is behind most of the "it worked in sub prod but not in prod" problems I have seen.
Get comfortable reading a failed run in Flow Executions instead of guessing.
Use flow variables properly rather than pushing everything into script steps. Try to build at least two of the above with no script step at all. It is harder than it sounds and it teaches you a lot.
You can watch this playlist, which is specific to Flow Designer and its use cases; this will help you gain deep and excellent knowledge of Flow Designer and its uses.
https://www.youtube.com/watch?v=tlul-PE8NpY
As a ServiceNow trainer, I’m happy to share my thoughts here. Since you asked for a real-world example, I would say that these concepts are mainly about understanding how users, use cases, and flows work together.
It can be difficult to decide which use case to start with, so I would recommend picking one practical use case and building from there. For example, the SN User Group may have organized a Buddy Agent challenge where community members participate and provide different user and Buddy experiences.
You can pick any one user from that example and build the Buddy flow around that user, rather than trying to understand the entire Buddy Agent concept at once. Starting with one specific user and use case will make it much easier to understand the overall concept and learn the functionality in a practical way.
Regards
Dr Atul G. - Learn N Grow Together ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
******************************************************************************************
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
an hour ago
Starting simple:
1. Auto assignment based on category and location. Incident is created, look up a routing table or the CI's support group, then set the assignment group. Good for getting used to data pills and understanding when to use Look Up Records versus Get Record.
2. Auto close resolved incidents. A scheduled flow that runs daily, finds incidents sitting in Resolved for more than 7 days, and closes them with a system comment. Covers scheduled triggers and looping over a record set.
3. Reopen on customer reply. Incident is Resolved, caller adds an additional comment within 5 days, flow moves it back to In Progress, reassigns to the previous assignee and sends a notification. Nice first use of Wait for Condition.
A bit more involved:
4. P1 major incident handling. Priority moves to 1, create a Major Incident record, notify the on call group, post a message to Teams or Slack, and start a 30 minute wait that escalates to the manager if nobody acknowledges. This one gives you parallel branches, timers and escalation logic in a single flow.
5. Multi level catalog approval. Manager approval first, then a second approval from the department head only if the cost crosses a threshold, then create catalog tasks in sequence. Build the approver logic as a subflow that takes the requested for user and the amount as inputs and returns the approver. Subflow inputs and outputs are the thing most people skip and then struggle with later.
6. Onboarding request with parallel tasks. One RITM creates IT asset, access provisioning and workspace tasks in parallel, and the RITM only closes when all three are done.
7. Change request routing based on risk. Evaluate risk and CI criticality, then send Standard changes to auto approve, Normal to CAB, and Emergency to a fast track group.
If you want something that will actually stand out on your CV:
8. Outbound integration with proper error handling. Incident is resolved, call an external system through an IntegrationHub REST step or a custom action, parse the response, and if the call fails, retry once and then log to a custom error table and notify the integration team. Handling the failure path is what separates a flow that works in a demo from one that survives production.
9. Inbound email to incident. Parse the subject and body, create or update the incident, then reply with the ticket number.
A few things worth paying attention to while you build these, because they come up again and again:
Run As and trigger security. Understand the difference between User who initiated session and System user. This is behind most of the "it worked in sub prod but not in prod" problems I have seen.
Get comfortable reading a failed run in Flow Executions instead of guessing.
Use flow variables properly rather than pushing everything into script steps. Try to build at least two of the above with no script step at all. It is harder than it sounds and it teaches you a lot.
You can watch this playlist, which is specific to Flow Designer and its use cases; this will help you gain deep and excellent knowledge of Flow Designer and its uses.
https://www.youtube.com/watch?v=tlul-PE8NpY
As a ServiceNow trainer, I’m happy to share my thoughts here. Since you asked for a real-world example, I would say that these concepts are mainly about understanding how users, use cases, and flows work together.
It can be difficult to decide which use case to start with, so I would recommend picking one practical use case and building from there. For example, the SN User Group may have organized a Buddy Agent challenge where community members participate and provide different user and Buddy experiences.
You can pick any one user from that example and build the Buddy flow around that user, rather than trying to understand the entire Buddy Agent concept at once. Starting with one specific user and use case will make it much easier to understand the overall concept and learn the functionality in a practical way.
Regards
Dr Atul G. - Learn N Grow Together ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
******************************************************************************************
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
59m ago
If possible share the concepts too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
47m ago
Regards
Dr Atul G. - Learn N Grow Together ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
******************************************************************************************