LogiUpSkill

Email Notification using Flow Designer

Email Notification using Flow Design Notification: A Notification in ServiceNow is used to automatically send messages (Email, SMS, Push) to users when a specific event or condition occurs.  Create Catalog & In Catalog Create Catalog item, For Requesting anything. Example [Work from Home.]  Add Variables in Catalog Items & Save it.               Employee Name               Address               Manager. This is Where we can Request anything like (Work from Home, etc.)  Creating Flow Design for Requesting Work from Home Application to the Manager & getting Response from Manager.  In Flow create Add actions, Create Emails for Request & Approval  Search Get Catalog variable from Action from Flow design.  In this Send Email action has been taken, and by this Request WFH email will go to Manager.    Ask For Approval – Approval must take from group of Manager.  If WFH is Approved from Manager, then Email will send to Employee or Requester.  If WFH will Rejected, then Email will go to employee or Requestor of Rejected Request.  Open Catalog Item Which was Created & Add Request for Work from Home  After Requested, there will be Request Number will be Generate. Click on that. It will Request Form  In Request Form there will be RITM click on that there will show Approves, in this there will Name of Approval Person   Results-:   The manager will receive an Email Notification that the WFH request is there.  When Manager will Approve or Reject that Request then the Mail will get to Employee that Request is Approve or Reject 

Concept of Inheritance in Service-now

Concept of Inheritance in Service-now Assignment 1- Concept of Inheritance in tables Parent_table Child_table 1 Child_table 2 While creating Parent_table, check the box : Enable extension under control section in the create table window.              Create fields in Parent_table as: P_first_name P_last_name P_phone_no  Create Child_table 1 by extending Parent_table as shown in the screenshot below.              In Child_table 1, create fields as: C1_first_name C1_last_name C1_phone_no Similarly create table Child_table2 extending Parent_table.  While creating fields in both Child_table 1 and Child_Table 2, it is seen that fields present in Parent_table is present in the 2 child tables. So the fields created in parent table reflects across all it’s child tables.  In Child_table2,create fields as: C2_first_name C2_last_name C2_phone_no Now , the relationship is created in such a way that Parent_table is the parent of both Child_table 1 and Child_table 2. This can be verified by searching for the parent table in the navigation bar Then click on Show Schema Map. The Schema for Parent_table is shown below: Create new records in all 3 tables and observe the records that are reflected between parent/child table.  Step1: In the above2 screenshots, we can see that  records added in Parent table are not seen in the Child_table 1 .The same is true with Child_table 2 also. Step 2:  A new record in Child_table 1 is created in the above screenshot.  When the Parent_table is checked, it is seen that the record created in Child_Table 1 is visible. So the data/ records in child table is reflected in parent table as well.  Step 3:  A new Record is created in Child_table2  It is observed that the new record from Child_table 2 is visible in Parent_table also.   It is finally seen that the fields are reflected from parent to child table, but the data/records are not. Also the data/records created in child table reflect in parent table but not the fields alone In summary, Fields/customization flows downwards and data/records flow upwards in Parent-Child Relationship. Concept of Inheritance in tables  When inheritance is established between two tables, the customization flows from parent table to the child table but the records/data flows from the child table to the parent table. Example: If two tables A and B are created such that B is a child of table A, then the fields created in table A are reflected in table B but records created in table A are not reflected in B.On the other hand, the records created in table B are reflected in it’s parent Table (A) but not the fields. While creating a UI Policy for a particular table, the same UI policy can be applied to it’s child table as well. This can be done by checking the ‘inherit’ checkbox while creating the UI Policy for that table.

Inbound Email Action in Servicenow

Inbound Email Action in Servicenow INBOUND EMAIL ACTION SCRIPTING   Requirement: Creating incidents for every single email attachment through inbound action.    Components Used: Inbound Action on Incident Table ‘sys_email_attachment’ Table ‘sys_attachment’ Table    Script for Inbound Email Action: (function runAction(/*GlideRecord*/ current, /*GlideRecord*/ event, /*EmailWrapper*/ email, /*ScopedEmailLogger*/ logger, /*EmailClassifier*/ classifier) {                 // Implement email action here               var emailSysId = sys_email.getUniqueValue(); // sys_id of email log record var qq=”email=”+emailSysId; //query to fire on sys_email_attachment table       var i=0;   gs.log(“Email sys_id is: ” + emailSysId, “EMAILSCRIPT”);                   var   gr = new GlideRecord(‘sys_email_attachment’);           gr.addEncodedQuery(qq);           gr.orderByDesc(‘sys_created_on’);           gr.query();           while(gr.next()){                                                          var gr1=new GlideRecord(“incident”);                                             gr1.short_description=”Attachment number”+i;  //Hardcoded short description                                             var t=gr1.insert();                                              i++;                                    var attachment = new GlideRecord(‘sys_attachment’);                              attachment.get(gr.attachment);                              attachment.table_name =”incident”;                              attachment.table_sys_id = t;                              attachment.update();          }   })(current, event, email, logger, classifier);

Workflow

Sub – Workflow Workflow is series of activities that follows execution path. An Activity is a collection of instructions that can include script, logging, approvals, record processing, timers, wait time, rollback activity etc. To create a workflow we need to go for workflow editor and we can drag and drop required activity in workflow. We can also drag and drop any other workflow in current workflow. We can create scratchpad variable to pass values from one activity to another. If we are using If activity then we can specify condition as follows- Following is the main workflow and we have added one sub workflow in main workflow. Sub Workflow- To send data from main workflow to sub workflow we need to create one input variable in sub workflow to hold value coming from main workflow as follows- We can specify input filed name, type, length etc as follows- Create scratchpad variable in main workflow Set value coming from main workflow to input variable Trainer Course To access value coming in input variable assign it to some other filed like short description To test this run the catalog item. Add Trainer name as Meghana. then automatically data present is scratchpad variable will be passed to sub workflow. After providing approval, check the workflow. short description should hold data coming from main workflow i.e. Service Now.   To send data back from sub workflow to main workflow we need to create scratchpad variable in sub workflow as follows – Then need to create return activity as follows and specify scratchpad variable as ${workflow.scratchpad.cost} Now go to main workflow and set map return value to as follows-   Then assign the value coming from sub workflow to description filed as follows, Main Workflow- Sub Workflow – Result- Incident Workflow Assignment Create Following Group’s 1.Email Group2.Phone Group3.Self Group4.Walk_in Group Create new state for Incident state field i.e. Waiting for Approval Incident Workflow         |         | Wait till the asigned to field should get value         |set state=Waiting for Approval         |         |Go for the approval according to Contact Type 1.Email ——Email Group2.Phone ——Group3.Self ——–Group4.Walk_in ——Group Any approval reject, it will go to run script activity where we should change the state=Canceled and then end the workflowAfter Approval         |         |         |Another approval should get trigger to Incident’s Caller’s ManagerIF the it reject , it will roll back to again the previous group approvalAfter approval it will go further         |         |         |Change the state=In Progress         |         |         |After this there should be 2 parallel process.1. if user canceled or closed the incident,then the workflow should end.2. if user changed the priority then put comments as “Priority changed” and go to Activity of Caller’s Manager Approval. but this priority changes can be done 2 times, if user is trying to do it for 3 times, then change the state=resolvedand end the workflow. Incident Form Field Task 1.Contact type field should have default value=Self Service2.User should not change the contact type field value once he submit the form3.User should not submit the form without categoy and subcategory field values Branch and Join        Branch flow Activity: The Branch activity is used to run the two activities parallel. The Branchactivity splits the workflow into multiple transition paths from a single activity. To add a transition path, select and drag the Branchactivity into the canvas. Then you can see the Branch activityproperties form displays, enter the branch name and click Submit to add the activity to the canvas, then click AddCondition. All transitions from this activity execute concurrently. This activity provides a single Always You can execute any number of transitions from this condition. Branching can affect the behavior of rollback activities.              Join flow Activity: The Join activity combines multiple execution paths into one transition path. To add Join to the canvas, Drag the join into the canvas and enter the name of join in the properties screenand click Submit. Use this activity for a workflow to wait for all activities in multiple paths to finish before it continuing. If multiple concurrentworkflow paths meet without a join activity, any subsequent activities execute two times. Connect incoming transitions from each activity you want to act as a predecessor to the Join activity. There will be two exit condition for the outgoing transitions: Complete and Incomplete. Complete: Joinexits along the Complete path when the system has determined that all predecessor activities havecompleted and transitioned to the Join. Incomplete: Joinexits along the Incomplete path when the system determines that at least one predecessor activitycompleted but transitioned along a path that bypassed the Join              Example: We have to set values for short description and description parallel when the wait for condition is true ->For that weuse Branch to run the two activity concurrently. We have to join two activity for approval user and approval group is approved then both condition satisfy it go toend -> For that we use Join to join that two activities.              Create Branch              Setting the values parallel for branch              Create approval user and group for join the activities              Create Join for two activities are approval user and approval group              Workflow for join and branch:              Output:              Branch output set the values for short description and description              Join output:              Once the user and group are approved the join go to end              Incomplete Join:              Usecase1:              If both approval user and approval group are approved then it show as complete. If approval user is approved and approval              group is rejected then it go as incomplete state.                Output for incomplete join:              Reject the approval for approval group and approved the approval user              Now it is in incomplete state then it go to end              If it is both are approved then it make as complete and go to end:              Usecase2:              If approval user is approved and approval group is rejected then it go incomplete then rollback condition