debranding final

Catalog Items - Flow.md

@@ -1,19 +1,19 @@
 # Creating a complete catalog item
 Objective: learn about catalog items, the request catalog, request items, business rules, variables, variable sets, UI policies, client scripts, and workflows.
 
-Login to the sandbox <https://snsandbox.ucsd.edu/>
+Login to your personal developer instance.
 
 ### Create the catalog item
 1. Go to the Catalog Items table (Look for Request Catalog Configuration > Catalog Defnitions > Maintain Items)
 2. Create new
 3. Fill out these values:
 	1. Name: [your name]'s Test Catalog Item
-	2. Catalogs: IT Services Request Catalog
-	3. Category: Student Practice
+	2. Catalogs: Pick an existing catalog in the picker
+	3. Category: Student Practice (you might have to make this if someone hasn't already made it for you)
 	4. Short Description: A catalog item designed for practicing servicenow admin fundamental skills
 	5. Portal Settings, Request method: Submit
 4. Right click the header and select save
-5. See if your catalog item shows up here <https://snsandbox.ucsd.edu/its?id=sc_category&sys_id=182b81851b903810331285d56b4bcb2c&catalog_id=-1>
+5. See if your catalog item shows up in your service portal (go to `your_instance_name`.service-now.com/sp)
 
 ### Add variables/variable sets
 1. Scroll down to the related lists section (the tabs at the bottom not to be confused with Related Links)
@@ -137,15 +137,15 @@ Note: Flows are powerful, and with great power comes great responsibility. It is
 14. In the flow field, add your flow and save/update your item
 
 Your catalog item now has this functionality:
-* Upon submission, the user is emailed letting them know that we received their request (this happens automatically without your configuration). (note that emails are disabled in sandbox so you won't actually see the email)
+* Upon submission, the user is emailed letting them know that we received their request (this happens automatically without your configuration).
 * If the user did not mark the checkbox question as true, then it will create a task for you to complete and the task will remain open until that task is completed before the flow continues.
 * If the user marked the checkbox question as true/checked, then it will send an approval request to you first, and upon approval the flow will continues
 * If the task is completed, then a "completed" email is sent to the user
 
 A lot more functionality just from a simple flow!
 
 Go and actually test these scenarios by submitting your form several times. You can see "approvals" and "tasks" show up on the request item record after you submit the form.
-* To approve or reject an approval you can either go here: <https://snsandbox.ucsd.edu/its?id=approvals>
+* To approve or reject an approval you can either impersonate the approver and check the service portal, or type Approvals in the app nav.
 * To complete a Catalog Task, go to the newly created request item and scroll down to the "Catalog Tasks" related list
 
 Did everything happen that you expected? **If this is not working for you, double check your Catalog Item to see if your Process Engine > Flow has your Flow there.**

Catalog Items - Workflow.md

@@ -1,7 +1,7 @@
 # Creating a complete catalog item
 Objective: learn about catalog items, the request catalog, request items, business rules, variables, variable sets, UI policies, client scripts, and workflows.
 
-Login to the sandbox with your admin credentials via the side door https://ucdavisietsand.service-now.com/side_door.do
+Login to your personal developer instance.
 
 #### Create the catalog item
 1. Go to the Catalog Items table (Look for Service Catalog > Open Records > Maintain Items)
@@ -13,7 +13,7 @@ c. Catalogs: IT Campus Services
 d. Category: Student Practice
 e. Short Description: A catalog item designed for practicing servicenow admin fundamental skills
 4. Right click the header and select save
-5. See if your catalog item shows up here https://ucdavisietsand.service-now.com/servicehub/?id=ucd_view_service2&sys_id=47fe399513e1df00d26f5e7f3244b028&ucd_catalog=5ec4eed5134143003527bd122244b0af&parent=93056219134143003527bd122244b024
+5. See if your catalog item shows up in your service portal (go to `your_instance_name`.service-now.com/sp)
 
 #### Add variables/variable sets
 1. Scroll down to the related lists section (the tabs at the bottom not to be confused with Related Links)
@@ -164,7 +164,7 @@ Your catalog item now has this functionality:
 A lot more functionality just from a simple workflow!
 
 Go and actually test these scenarios by submitting your form several times. You can see "approvals" and "tasks" show up on the request item recordafter you submit the form.
-* To approve or reject an approval you can either go here: https://ucdavisietsand.service-now.com/servicehub/?id=ucd_my_stuffand click on "My approvals" or go to the newly created request item and scroll down to the "Approvers" related list
+* To approve or reject an approval you can either impersonate the approver and check the service portal, or type Approvals in the app nav.
 * To complete a Catalog Task, go to the newly created request item and scroll down to the "Catalog Tasks" related list
 
 Did everything happen that you expected?

Record Producers.md

@@ -1,9 +1,7 @@
 # Creating a Complete Record Producer
 Objective: learn about record producers, and server-side scripts.
 
-Login to the [sandbox](<https://snsandbox.ucsd.edu/>)
-
-<br>
+Login to your Personal Developer Instance
 
 ### Create the Record Producer
 1. Go to the Catalog Items table (Look for Request Catalog Configuration > Catalog Defnitions > Maintain Items)
@@ -15,8 +13,6 @@ Login to the [sandbox](<https://snsandbox.ucsd.edu/>)
 4. Click Submit at the bottom left
 5. You've now created a record producer. Find your record producer on the Record Producers table, and select it.
 
-<br>
-
 ### Editing the Server-Side Script
 1. In your record producer, find the "What it will contain" tab (should be just below the Record Producer's fields) and make sure it's selected
 2. In that tab, scroll down to the "Script" section. This is where the server-side script is (i.e. run by the backend, not the frontend)<sup>1</sup>
@@ -41,8 +37,6 @@ current.u_variables.display = true;
 
 Server-side scripts can get much more in-depth. You can use [ServiceNow's Glide class](https://docs.servicenow.com/bundle/paris-application-development/page/script/general-scripting/reference/r_GlideClassOverview.html) to edit databases at scale, execute server-side code directly from the client, create custom forms, etc. It is very powerful! But with great power comes with great responsibility! **Even so much as one messed up capitalization in a server-side script could ruin the whole UCSD database! Be careful, and always contact your supervisor if you're not sure a script will run as intended!**
 
-<br>
-
 ### Mapping Variables to Case Fields
 This section will introduce the creation of variables, using the GlideSystem (or ```gs```) to get logged-in user information, and mapping a variable to a field in a generated case.
 1. Go to your record producer and create a new Variable
@@ -61,17 +55,13 @@ Now what have you done so far? You've created a variable that will map to a fiel
 
 In the future, you'll be messing with even cooler scripts that will be able to automate many more things (you can even make a form that will send text messages to people, or make a robot send messages to your slack channel)!
 
-<br>
-
 ### Server-Side Print-Debugging
 1. For server-side print-debugging, you will have to use ```gs.info()``` and then look in System Logs > Application Logs for the information that is logged
 2. A rule of thumb for ```gs.info()``` calls is to format it as ```gs.info([your name] - , ...)```. This is because, in the SNOW-Development environment, there are tons of forms printing info at the same time, so it will be impossible to find your own if you do not prepend your name to your console output. Example:
     ```javascript 
     gs.info('rickesh - ' + gs.getUser());
     ```
 
-<br>
-
 ### Record Producer Accessibility
 This section is mainly meant as a heads-up (you are not changing values on your record producer). Right now, your record producer is considered 'Unlisted'. That means that no one can access your form unless you give them the direct link to access it. Well that's kind of annoying, so let's change that:
 1. Go to your Record Producer and find the "Accessibility" tab.
@@ -80,8 +70,6 @@ This section is mainly meant as a heads-up (you are not changing values on your
     * Category is a sub-category that belongs to the department.
 3. Although, we won't be changing these, keep in mind that this is how forms are listed and unlisted for UCSD.
 
-<br>
-
 ### Footnotes
 1. This is different from client-side scripts. Client-side scripts run in the frontend and any ```alert()``` calls for client-side print-debugging will actually be visible on the form itself. Client-side scripts will run _as an action is performed or when the form loads_. This is not true for server-side scripting. For record producers, scripts will run _after_ you submit the form. For debugging details, see Server-Side Print-Debugging
 2. Variable Explanations

Standards/API Usage.md

@@ -3,7 +3,7 @@
 ## Outbound
 
 - Outbound calls to external APIs via REST, SOAP, or other methods are allowed.
-- Do not store API keys in plain-text on scriptstable records, instead put them in system properties.
+- Do not store API keys in plain-text on scriptable records, instead put them in system properties.
 - Intentionally rate limit outbound calls that occur rapidly (several per second). Make sure these calls are condition-based for when they occur instead of timer based.
 - Do not use ServiceNow to call an external API to check for updates rapidly. If you need live updates, attempt to create an inbound integration that is triggered by the external system, instead of polling for updates.
 - Prefer creating outbound service records that are called in script rather than creating an entire outbound call in individual scripts.

Standards/Catalog Items.md

@@ -3,31 +3,30 @@
 Request catalogs and their catalog items (forms) are used to describe, support, and request services from service providers. 
 
 ### Catalog Item Style Guide 
-- Use the standard style guide to design catalog items. 
-- The catalog request item style guide is maintained on the ServiceNow in knowledge article KB0000991. Printed copies are considered drafts. 
+
+- Use your company provided style guide to design catalog items. 
 
 ### Request Catalog Style Guide
 
 This style guide is a set of standards to help the information technology community develop ServiceNow Request Catalog items.
 
 This style guide follows:
-- Guidelines provided by Strategic Communication which can be found at http://marketingtoolbox.ucdavis.edu
 - The Associated Press (AP) style guide and The Chicago Manual of Style, which UC Davis Strategic Communication follows
 - ServiceNow product documentation
-
-In addition to the standards listed above, the Information Educational Technology web development team has guidelines that can be referenced on their service page at http://itcatalog.ucdavis.edu/service/web-development.
 
 #### Audience 
+
 - Staff who have oversight and content management responsibilities for ServiceNow
 - IT community developers who work on ServiceNow modules, applications, and system components utilizing the Item Designer
 
 #### Purpose
+
 The Request Catalog is for service offerings. Services offerings may include both products and services.
 
 #### Request Item Writing Tips
 
 - **Avoid capitalizing every word in a header, question or phrase**. The first letter of the first word of variables in a catalog item should be capitalized (i.e. Phone number). Capitalize professional titles, organizations, and other proper nouns, but in general, avoid the use of caps.
-- **Avoid the use of acronyms**. If an acronym is required, the full name should be written out the first time it is used with its corresponding acronym in parenthesis (i.e. Information and Educational Technology (IET)).
+- **Avoid the use of acronyms**. If an acronym is required, the full name should be written out the first time it is used with its corresponding acronym in parenthesis (i.e. Associated Press (AP)).
 - **Use clear and concise language**. For variable questions, typically verbs are not necessary. (i.e. “Requestor’s job title” rather than “Enter the requestor’s job title.”)
 
 #### General Formatting
@@ -64,6 +63,7 @@ A cascading style sheet (CSS) has been created that adheres to University guidel
 6. **Multi line vs Single line** Question dependent, but multi lines should only be used for lengthy questions such as asking for additional detail.
 
 #### Guide to Usability
+
 - **Tooltips** (rollover or hover functionality) are the primary method used for "help text." The majority of variables in a form will require a tooltip; the exception to this standard is when the variable name is its definition.
 - **More information** should be used sparingly in support of more complicated content within the variable. This is a secondary solution to the tooltip. More information appears in grey under the input field. Do not include information directed to an individual or group, requirements, or terms and conditions. 
 - **Common variables** used in form design: