javascript:(function(){var a=window.location.href; if(0<=a.indexOf("navpage.do") ||0<=a.indexOf("nav_to.do") ||0<=a.indexOf("workflow_ide.do")) alert("Looks like you're already inside a frame!"); else if(0<=a.indexOf("service-now.com/") || 0 <= a.indexOf('wwwsnow')){var b=a.indexOf("://"),b=a.indexOf("/",b+3)+1,c=a.slice(0,b),a=a.slice(b);window.location.href=c+"nav_to.do?uri="+a} else alert("That only works on ServiceNow pages.")})();

- Did not seem to work until I uploaded an image with an actual “.ico” extension. - glide.product.icon - If the image is not found, the system will display a GLOBE icon in the browser tab by default. - System Properties - System - “icon image displayed in bookmarks and browser address bar”. Same as the above setting. - System Properties - My Company - This is used for the icon in the Banner, not the browser tab icon.

For the favicon,

1. First, Upload the new image filter navigator>System UI>Images and click 'new'
2. Enter a name for the image. Must end in .png .ico .gif .jpg or .bmp
3. Click the link in the image field, then select and upload the image
4. Click 'update'
5. Next, navigate to filter navigator>System Properties>System
6. Scroll toward bottom until you see the current favicon
7. Update the name to your new image. i.e. faviconPROD23.png?v=5 add the ?v=5 after the .png then save
8. Refresh your page to see the new favicon

https://docs.servicenow.com/en-US/bundle/utah-platform-administration/page/administer/navigation-and-ui/task/t_DefineFieldStyles.html
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0584393
https://www.servicenow.com/community/developer-forum/how-to-get-styles-to-work-on-a-form-field-not-just-the-list/m-p/1868643

1. Field styles allow you to declare individual CSS styles for a field in a list or form.
2. But only applies to form fields if they are in a READ ONLY state, that is they are disabled.
3. Field styles must be declared separately for Tables and Database Views.
4. The CSS lets you change the following attributes of a field.
5. Color.
6. Font attributes (bold, italics, underline).
7. Padding and alignment of text.
8. To get to the field styles for a filed, right click the field label and select “Configure Styles”.
9. Value Field
10. Represents the exact value or script-based condition required to apply the style.
11. You can use a script-based-condition with the syntax “javascript:<script>” in the Value field to determine whether the system should apply a style to a field in the list. If the evaluated script returns true, the system applies the style to the list item.
12. The script has access to the current script object, which enables you to build conditions based on the field values of the current record.
13. Style examples

“background-color:red;

font-size:24px;
color:white; 

- When do Field Styles Apply?

1. On List Views
   1. Always
      1. When the field is Read / Write
      2. When the field is Read Only
2. On Forms
   1. Only when the field is Read Only (yes, this is strange)
   2. When the field is Read / Write AND there is no condition whatsoever applied to the Field Style.

- If you do need Form Field Styles to be conditional for read/write fields, you will need to apply them conditionally in a Client Side Script, rather than relying on a Field Styles object. Article Link: Link - Quirks - When you use the “background-color” style, you will get a DOT next to the value in List Views; the entire background will not be changed to the color you indicated.

“Field Decorations” are small icons which may be displayed to the left of a field to draw attention to the field, and upon Hover, provide a Hint to the user. example:

- Resources - The addDecoration() and removeDecoration() methods are a part of the client-side GlideForm API, documented here: https://developer.servicenow.com/dev.do#!/reference/api/quebec/client/c_GlideFormAPI

- A good article on the history of field decorations is available here: https://community.servicenow.com/community?id=community_blog&sys_id=925eaaaddbd0dbc01dcaf3231f961940

- Example Script

- Quirks As of 07/20/2021, there may be a problem with REMOVING decorations which have been added with the addDecoration() method which takes a 4th parameter, the COLOR parameter. When a colored decoration is applied, it seems like the “removeDecoration()” method does not function. If there is a requirement to both add and REMOVE decorations, colored decorations should be avoided. Example:

	//g_form.addDecoration("business_service", sIconStyle, sDecorationMessage, "color-blue");  //Works, but can't then be removed.

… g_form.removeDecoration(“business_service”, sIconStyle, sDecorationMessage); This will fail. - Discussion of this issue may be found here: https://community.servicenow.com/community?id=community_question&sys_id=a266be48dba677402be0a851ca9619a1 —- ====== Field Maps ====== If an inbound Choice List value is not found in the reference table, there are 3 different behaviors that may be configured, for what to do. This is called the “Choice Action”. For example, say you are importing into the Incident table, and an unexpected value comes in for the “Category” field which is a String field with a “Choice List Specification” of “Dropdown with – None –“… For the Category field map, there are 3 different Choice Actions and they will behave as follows: Create - A brand new value will be created in the sys_choice_list table, and it will be available for all Incident records from now on. Ignore - The Category filed will simply be ignored. No value will be set, and it will have a value of “None”. Reject - The entire database record will be rejected and an error message will be returned in the Response message, such as the following: “result”: [ { “transform_map”: “UIncident_to_Incident_Transform_Map”, “table”: “incident”, “status”: “error”, “error_message”: “Choice field value for incident.category rejected: Bozo3; Target record not found”, “status_message”: “Choice field value for incident.category rejected: Bozo3” } ] - Example Field Map Source Script answer = (function transformEntry(source) { if (source.assignment_group == ””) return “CommandCenter” else return source.assignment_group; })(source); ====== Fix Scripts ====== - Role Script_fix_admin - Server side JavaScript that executes when an Application is Installed or Updated. - Used for making changes that are necessary for the data integrity or product stability of an application. - Can run before or after an application is installed or updated. - To Test a Fix Script - Select the Run Fix Script related link, then choose either Proceed in Background or Proceed (in foreground). For Fix Scripts which are run in the foreground, results are presented in a confirmation window. ======Flows - Flow Designer ====== - Takeaway - A Workflow is a designed sequence of decisions and actions, linked together for the purpose of automating a business process. A “Flow” is a specific type of workflow composed in the graphical “Flow Designer” tool in ServiceNow. Flows are compiled out of reusable components and in many cases may involve No Code or Low Code. A Flow has a Trigger which specifies under which conditions the Flow will be executed. Each Flow “Action” has its own Inputs, Steps, and Outputs. The Outputs of an Action may be used as “Data Pills” (variables) in all subsequent actions. A Step is a unit of work within an action. A Step may do things such as change a record, send an email, run a script, make a log entry, run a REST method, or wait for a Condition. “Flow Logic” components provide looping, branching, “Forking” and Delay functionality within a Flow. A common set of actions may be encapsulated into a SubFlow. A SubFlow does not have a Trigger, as it must be executed from a Flow. A Flow, SubFlow, or Action may be launched from a Server Side Script using the Flow API. - Modules Decision Tables - Decision Tables Table: sys_decision Flow Designer - Active Flows Table: sys_flow_context Process Automation - Flow Administration - Today's Executions Table: sys_flow_context Process Automation - Flow Designer - Roles: action_designer - Launch the Action Designer environment. Create and edit custom actions. flow_designer - Launch the Flow Designer environment. Create and edit Flows, SubFlows, and Actions. - Caution! This role is basically the equivalent of the Admin role since Flow Designer can run as the System user, which has access to all tables and all database operations. flow_operator - View (only) flow execution details, dashboards, and logs. - Hierarchy Flow Trigger Action 1 Inputs Step 1 Step 2 Outputs (Data Pills from Action 1 now available) Flow Logic 1 Flow Logic 2 SubFlow 1 Sub Flow 2 Action 2 Inputs Step 1 Step 2 Outputs (Data Pills from Action1 and Action2 now available) ===== Flow Designer ===== - Flow Designer is a design environment used in the Now Platform to develop and manage flows. - Flow Designer is a (somewhat) non-technical interface for repeatable process automation, without code. - With IntegrationHub, Flow Designer can even be used to integrate with third-party systems. - Flow Designer is a separate User Interface from the Platform UI; it opens in its own tab if launched from the Platform UI; it opens in its own Window if launched from Studio. - Reduces development costs by providing a library of reusable flow components in the base system, created by ServiceNow developers. - Reduces upgrade costs, with upgrade-safe platform logic, replacing complex custom scripts. - Note: Flow Designer does NOT automatically Save changes. Click the Save button to save a flow. - Note: From the Flow Designer Test Results window, you can click a record number to Preview a record. Form there you can click a button to Open the record. You can then make changes to the actual record and return to Flow Designer. If you Reload the Test Results page, the workflow will show updates, and you can continue to Test / Debug. This method minimizes navigation and changing tabs and windows. - Important: Every time a flow runs, details about the configuration and runtime values produced are available in the design environment. With the flow open, click the Executions button. - Access to Flow Designer: - - Administrators can grant users access to Flow Designer features in one of two ways: - - By granting one or more Flow Designer Roles (equivalent to granting the admin role). - By assigning the Flow Designer delegated development permission. The ensures that the delegated developers can only access Flow Designer for a specified application scope. - System Applications - Studio - [MyApp] - File - Mange Developers - [Whoever] - Flow Designer (on). - When a Flow is activated, it will show up under Filter Navigator - Flow Designer - Active Flows. - “Open in Operations View” may then be used to see what Action the flow is paused on. - Flow - A Flow is a sequence of actions to automate a process on the Now platform. - A flow performs a predefined process every time it executes. - Each flow consists of a trigger and one or more actions. When the conditions of the trigger are met, the flow will execute the actions. - Allows Business Process Owners to use (somewhat) natural language to create workflows without having to write any code. - Flows may be used to automate/implement business logic for approvals, tasks, notifications, and record operations. - A Flow consists of a set of properties, a trigger, a sequence of actions, and the data collected or created. - Quirks - A Flow may be set to “Read Only” to prevent editing by other developers. If the Read Only flag is set, and you don't know why, try performing a Source Code Commit operation, and look for update sets by different users. If you see an unexpected user, the flow may belong to that user and you may need to impersonate that user in order to take the flow out of Read Only mode. - Testing - Flows may be Tested after they are created using the Test button directly within ServiceNow Designer. - Testing should only be done in the Dev or Test environment, as the changes made to records are real and permanent. - When testing, the Trigger executes even if the conditions normally would not be met. - There is no Rollback feature. - There is no “Run As” feature. - You can manually select a Table and Record for the test run. - Flows are built using just three component types, Triggers, Flow Logic, and Actions. - Tip: When building a Flow, remember to first Search for SubFlows. There may be useful components already pre-constructed that you can utilize. - Flow Execution Details: Flow Execution Details - Steps to building a Flow which should be followed by a Process Designer: - Understand what you want to build. - Capture every step of the process to be automated. - Ensure the design is thought through (with various use cases) before you develop anything. - Review the design with various stakeholders. - Variables - Triggers and Actions create and populate variables. - To use a variable, drag a Data Pill from the Data Panel onto an Action configuration field. - Note: If a data pill from a previous Action is unavailable, be sure to Save the flow, and it may become available. - Some text fields allow plain text to be mixed with data pill variables. - Context - The starting configuration, and runtime environment, for a currently executing (or completed) flow. - The Flow Designer provides a wealth of context information about a currently executing or completed flow. - Used to store the flow execution details including runtime duration, log messages, configuration values, runtime values, outcome state. - Flow States: - Modified - Has been changed, and changes have not yet been saved to disk. - Draft - Changes have been saved, but the flow is not active. - Published - The flow is saved, active, and ready to go. - Run As A flow may run as one of two accounts: - User who initiated the session - Must have permission to execute all flow actions or the flow will fail with an error. - Note: When a flow updates a record, the “Updated” field will reflect the user that the flow ran as. (This could be misleading since the user didn't do anything manually or explicitly.) - System User - Not a record in the User table, but a service account that is Not restricted by access controls. - It is a best practice to test Flows with a user who has the minimum roles/privileges necessary to execute all the actions of the flow. - When a record is sent for Approval (Ask for Approval Action), be aware that the Action state may be either Waiting or Completed, and once completed, the returned Approval State may be Cancelled, Approved, or Rejected. Cancelled means that the record failed to meet the Approval rules, but was not explicitly rejected by an approver. - Flow Processing works as follows: - Event Queue - Every time Trigger conditions are met, the Scheduler creates an entry in the Event Queue. - Process Event / Start Flow in Background - Each flow event contains a reference to the flow itself and also to the triggering record (or the execution time, for scheduled flows). It is typical for there to be a delay (lag) between when a trigger condition occurs, and when the flow actually starts. - Process Plan Constructed - When the system pulls an event from the queue, it checks for any recent updates to the flow. If there are not any, it uses a cached copy; otherwise it builds a new process plan on the fly. - Process Plan Executed - If the flow involves a record (typical), the version of the record at the time the flow was triggered is used, unless an action in the flow specifically requests an updated version from the database. - Outcome State may be one of the following: - Complete - The flow completed successfully. - In Progress - The flow is running. By default, flows are not permitted to run for longer than 1 hour. - Waiting - The flow is waiting for another even to occur, for example, a user to update a task or make an approval or for the record to reach a certain state. While in a waiting state, the flow is written to a context record (and presumably removed from memory). - Cancelled - The flow was specifically cancelled by a user. - Error - The flow encountered an error (such as a missing input value) and stopped running. - Action - An operation performed by a Flow. - An operation which may be reused by a Process Designer, without the need to write code. - Consists of defined Inputs, one or more Steps of work, and Outputs (used to create data pill variables) for use by subsequent flow Actions. - Actions are categorized as Core, Global, or Application. - Annotations may be added to help make Actions more human-readable. - Actions have properties such as a Name, Accessibility, and Description. - Actions are operations executed by Flow Designer, such as looking up a record, updating a field value, requesting an approval, or logging a value. - Each time you add an Action to a Flow, Flow Designer adds a “Data Pill” to store its Output results. These may be used in subsequent flow Actions. - Every Action has a different set of configuration fields, based on what the Action does. - Note that Actions do NOT need to be a part of the same Application as the Flow which consumes them. - See Action Steps, below. - Custom Action - Functionality that is not available in the base instance. - May be created with little to no code, however scripting is available. - Guidelines: - Keep it simple (just a few steps). - Use a human-readable name. - If an action seems to be getting complex, consider if a SubFlow might be more appropriate. - Inputs - Use advanced input options on reference inputs to configure Reference qualifier conditions to limit the records available to select in a flow. - Testing - An action may be tested directly while it is under construction, using the Test button in the header. - You supply a value for each input parameter, and then hit the Run Test button. - To test an action inside a Flow, add the action to the flow and click the Flow's Test button. - A newly created Action is called a Draft Action. To test a Draft Action, the Flow must have a status of Draft or Modified, and the “Show Draft Actions” toggle must be set to true; this is set under More Actions - Configurations - Show Draft Actions. - Step - A unit of work within an action. - Can manipulate a record, send an email, send a notification, run a script, create a log, run a REST web service request, or run a PowerShell script. - Tip: Steps cannot be re-ordered in an Action once added; they must be removed and re-created. - States Draft - In development. May not be used in a Flow unless the Flow specifically allows Draft Actions. Published - Ready for use in a Flow. - Core Steps - ServiceNow-provided steps which are available to any Action of a Flow or SubFlow, such as the following: - Ask for Approval - - Attachments - Copy / Delete / Get / Lookup / Move - Create, Update, or Delete a Record - - Create Task - The flow may be paused until the task is completed. - Email - - Integration - Integration Hub is Required for these Steps! - Log - Write to the Log - Lookup Record(s) - - Notification - - Script - Executes Custom Server-Side JavaScript. - Scripts include their own Input and Output variables (separate from those of the Action) to map Action data to JavaScript data. - Inputs - An “Inputs” object is automatically instantiated and exposes the previously-defined input variables as object properties. - Use the syntax inputs.variableName to use an input variable in the script. - Outputs - An “outputs” object is automatically instantiated and exposes the previously-defined output variables as object properties. - Use the syntax outputs.variableName = valueFromScript to set the value of an output variable. - Output variables create data pills to pass data from the script to other steps or action outputs of the Action. - Script Steps that interact with an external application, through REST or API calls, require a subscription to IntegrationHub. - Wait for a Condition - Pause the flow to wait for a state change on a record. - Flow Logic - Used to specify Conditional or Repeated actions. - Note that Flow Logic is NOT available in an Action; only in a Flow or SubFlow. - Branch Types Includes: - If - Else - Else If - Make a Decision Decision Table - Used as an alternative to nested If, Else If, and Else flow logic. - Geoff: Honestly, this feature is Very Complicated, and requires a lot of Configuration in several different places. I found it to be a lot more trouble than it is worth. I think the additional layers of configuration will make your logic branches MORE error prone and difficult to debug, not less so. - Supposedly simplifies how branching logic is configured in a Flow; similar to a Truth Table or Decision Table. - Each “Decision” record is the list of conditions used to reach one answer. - A Decision table is mapped to an Answer table using Decision records. - Steps: 1) Create an “Answer” Table. Define columns. Populate with Rows. This is a regular old table. 2) Create a Decision Table 2.1) Create Decision Inputs (Related List) Seems like I had to define a lot of information which was already defined in other tables. ??? 2.2) Create Decisions (Related List) 5) Configure the “Make a Decision” flow logic. - For Each - Used to execute an action on a block of Records returned by the “Look Up Records” action. - Do Until - Do in Parallel - Note: Output values will only be accessible to the whole flow or SubFlow when all the parallel actions complete. - Wait for Duration of time - Call a Workflow - End (terminate) - Impersonate - Assign SubFlow Outputs - Important. Used to actually get values into the outputs of the SubFlow so they can later be used as Data Pills. - The actions in a flow logic branch are called a block. - SubFlow SubFlows - A sequence of actions that can be launched from a Flow, another SubFlow, or a Script. - Encapsulates complex functionality, allowing it to be reused over and over in multiple applications or processes. - A SubFlow helps with maintainability. - A SubFlow does not have a trigger. - Note that Script Steps are NOT available in a SubFlow. - Allows a Process Designer to construct reusable logic without writing code. - Only a Published SubFlow may be selected for use in a Flow. - Note: To Create a SubFlow in Developer Studio, create a Flow, and then on the next page of the Wizard, select SubFlow. - Inputs - A SubFlow has typed Inputs to make data available to its Actions. - Input data is referred to in the SubFlow by the label specified. - Outputs - Data is returned via typed Outputs. These can be used (as Data Pills) by the module that called the SubFlow. - Output data may be referenced by the label specified. - You can use the Flow Logic component “Assign SubFlow Outputs” to set a value to each Output that will be returned from the SubFlow. - Trigger - Specifies the condition that starts the flow: - Advanced Options allow you to specify that a Flow should only run for a specified set of users. - Note: If you setup a record trigger to run “For each Unique Change”, and for “Non-Interactive Sessions”, and the Flow itself updates the record, you can get into a recursive update situation (endless loop). Something to watch out for. - Each time a Flow is triggered, an event entry is generated. - Types: - A record is Created, Updated, or Deleted. - A Date (previously called a scheduled event) - Daily, Weekly, Monthly, etc. - Use Cases for Scheduled (Date-Driven) Triggers include: - Notifications to users of overdue tasks. - Automatic creation of tasks to perform on a regular basis. - Validation of data. - An inbound email. - A Service Level Agreement (expiring?) - A Script - Application Based: - MetricBase - This relates to the “MetricBase” application. - A “MetricBase” trigger tracks time series data. (Note, these are NOT available on Personal Developer Instances). - Only available when the MetricBase application is active. - Use cases: - A Threshold is reached. - A Trend is detected. - No data is received from a metric. - Service Catalog. (Request created.) Option available when the “Flow Designer Support for the ServiceCatalog” plugin is activated: Activate Flow Designer Support for the Service Catalog - Typical triggers for a Flow include Record Actions, a particular Date/Time being reached, inbound Emails, SLA expirations, Application-Based, explicit triggering from a Script, or the creation of a service catalog Request. - Flow API - Published Flows, SubFlows, and Actions can be initiated from Server Side Script using the Flow API (sn.FlowAPI object). - Methods: Synchronous: executeFlow(FlowName, Inputs) executeSubFlow(SubFlowName, Inputs) executeAction(ActionName, Inputs) Asynchronous: startFlow(ActionName, Inputs) startSubFlow(ActionName, Inputs) startAction(ActionName, Inputs) Example Usage: Map inputs. For a flow with a record trigger, inputs are the record and table

		var inputs = {};
		inputs['current'] = current; 	// GlideRecord of table:  
		inputs['table_name'] = 'incident';
	
 // Execute the global flow called test_flow 
 sn_fd.FlowAPI.executeFlow('global.test_flow', inputs);
- They may be run synchronously or asynchronously.
- Flow Designer provides code snippets to use Flows, SubFlows, and Actions in Scripts!
	- From Flow Designer, select the More Actions button, and select the Code Snippet menu item.

- One reason to use Workflow instead of Flow Designer is if a Service Level Agreement (SLA) Timer is required. Workflow is ServiceNow's original drag-and-drop interface for automating multi-step processes across the platform. - There is really no way to see the Code generated by the Flow Designer. - zMisc - Remember, Flows can have triggers other than Catalog Items! Can execute once a day, for example!!

1. To revert to a previous version of a flow:

https://community.servicenow.com/community?id=community_video&sys_id=85981caadb86cdd0e515c223059619f4

1. In flow designer Home, right click a flow and choose Copy sys_id. Then in table sys_update_version look for *TheSysId in the Name field.
2. Then you can open any version and revert to that version.

- Takeaway A Form is a user interface for working with the fields of single database record, and directly related records. A Form has multiple “Views” which may be configured to show different subsets of fields from the record's table. A user may Personalize his own Views of a form, and turn on or off different fields. A “Formatter” is a complex form element which displays data related to, but NOT contained directly in, the current record. The Activity Stream is a formatter; so is Related Search Results. The Activity Stream shows all recent activity associated with the record. The Form Design tool provides a graphical canvas to make it easy to design and layout a form. Form Design and Table Design go hand-in-hand, and you can use the Form Designer to add new fields to the underlying table. - A form displays data from a single record in a table; and possibly data from records in related tables. - In ServiceNow, forms and tables are tied closely together. Every form is based on a table. - Using Forms: - You DO need to click Save or Update at the top right of a form in order to save form field changes. There is no auto-save concept. - The Personalize Form icon, which looks like 3 slider controls, and normally appears to the Left of the “. . .” control at the top right allows individual form fields to be displayed or hidden. - Clicking on a Connect notification opens the Connect Sidebar on the right hand side of the screen. - A “journal” field is where you can provide notes on a record which will be viewable by different groups of users. - Some forms have Sections which may be optionally be configured to appear as Tabs. - Hidden Feature: File attachments may often be dragged onto a form header. - Activity Stream - The Activity Stream icon, which looks like a Heart Pulse, shows all the recent activity associated with the current record.

1. It may just scroll you down to the Work Notes section of the form.

- The funnel icon to the right of the activity stream allows you to filter the types of activities which are displayed. - Following a record, using the “Follow” button at the top right, adds the logged in user to the Activity Stream “Conversation” in “Connect”, and activates notification for any new comments/notes. - At the BOTTOM of the Filter Activity checkbox list, there is a Configure Available Fields (Configuring Activities) hyperlink. This allows an administrator to configure which fields will be available to ALL users. This values are stored in a comma separated list in a system property. https://[YourInstanceName].service-now.com/nav_to.do?uri=%2Fsys_properties_list.do%3Fsysparm_query%3DnameENDSWITHactivity.fields%26sysparm_first_row%3D1%26sysparm_view%3D

1. The Activity Stream User Preferences are stored in the sys_user_preference table under a name such as “incident.activity.filter”.

- Views:

1. Views are different ways for looking at the same record.

- Each form has different “Views” you can configure; Each view presents a different set of fields from the underlying table. - Some users can display many different Views of a form via the Additional Actions menu - View. - A Form View allows you to present a different set of fields from a form to different Roles, or for different use cases. - A view cannot be changed for unsaved records. To test a view with a new record, you must first populate all mandatory record fields and save the record. It is faster to test views using an existing record. - The current view name appears in square brackets [ ] next to the record number. In the default view, no view name is displayed. - Client Scripts and UI Policy Scripts can execute selectively based on a particular View. - Users require the view_changer role to change views. - Fields: - In a Reference field, a user selects a value from a related table. Not all dropdowns (selection controls) are reference fields. - A List field (such as “watch list”) accepts multiple reference values. - Some fields are dependent on (conditional on) the values of other fields. Field B may only be displayed if field A has a certain value. - Formatters: - A “Formatter” is a complex form element which displays data related to, but NOT contained directly in, the current record.

1. The Activity Stream is a formatter; so is Related Search Results.

- Form Design: - Provides a graphical user interface for designing form views. It makes the layout easy to see as you are designing. - Note that when a new table is created, a form is also automatically created. - Provides a modern interface for configuring forms. It combines several configuration options into one tool. - With a record open, go the Additional Actions menu, then Configure - Form Design. - When you launch the form Designer, the second selection control at the top allows you to select the form View to edit. - You can add existing table fields to the form using the “Fields” tab at the top left. - You can add brand new underlying table fields (custom fields) by selecting a “Field Type” from the tab at the top left. This will automatically give the field an ID such as u_price_1, but you can rename the default ID. Form Design and Table Design go hand-in-hand. - You can add annotations in between form fields, and type in instructions or additional helpful information.

1. Do this from the “Field Types” tab. “Annotation” is towards the bottom of the list.
2. Unfortunately, the annotations are quite Invasive compared to the fields.

- New Forms may be created in Studio using the “Create Application File” button. - Form Layout: - Configure - Form Layout is another (older) way to configure forms. - Related Lists

1. See also “Related Lists” section in this document.
2. Accessed with a record open, and then Configure - Related lists.
3. The Related lists section will not appear for a brand new record until it is saved to the database.

Sections / Tabs - Sections organize forms fields into logical groupings. - With scripting, sections can be hidden when they are not needed. - By default, sections appear as tabs on a form, but if tabbed forms are disabled, sections appear sequentially at the bottom of a form. - zMisc - If an update happens in real time while a user is viewing a form, a pulse icon appears next to each field which was updated. - Important: The fastest way to see the underlying table name of a form field is to right click it and look in the speed menu under “Show…”. - The Insert menu command is used as follows. You open up a record which is similar to the record you want to insert; you make changes; then, rather than Saving the record, you choose Insert. This leaves the initial record unmodified. (Seems dangerous, because you could easily choose save instead, accidentally, and you would then end up changing values for an existing record rather than creating a new record. - Right click a form label to edit the choices or add new choices. There are multiple ways to do this. - If you are seeing Field or Sections of fields that are Grayed Out / Read Only / Disabled, it may be a scope issue. The field may be defined on a different table from the Scope you are currently working in.

-Table

sys_template 

- Form Templates allow you to quickly populate a group of form fields, all at once. - To access Form Templates, under the More Options menu, go to “Toggle Template Bar”. - Click a Template in the template bar to apply an existing template to a form. - Fields set via a template are designated with a special icon, a gray checkmark inside of a circle. - You can create a new template directly from a form by simply filling in some of the form fields and then clicking the + icon in the template bar.

- Important: You can create a shortcut (toolbar button) to restore the ServiceNow “Frame” or “Chrome” that includes the Filter Navigator and header. Replace the URL of any shortcut with the following: javascript:(function(){var a=window.location.href; if(0⇐a.indexOf(“navpage.do”) ||0⇐a.indexOf(“nav_to.do”) ||0⇐a.indexOf(“workflow_ide.do”)) alert(“Looks like you're already inside a frame!”); else if(0⇐a.indexOf(“service-now.com/”) || 0 ⇐ a.indexOf('wwwsnow')){var b=a.indexOf(“:”),b=a.indexOf(“/”,b+3)+1,c=a.slice(0,b),a=a.slice(b);window.location.href=c+“nav_to.do?uri=”+a} else alert(“That only works on ServiceNow pages.”)})(); —– =====Flow Designer - Accessing Data elements from previous actions in script===== —–