What automations would you implement first in a nearly blank ServiceNow instance?

[douglastozi]

Hi everyone!

I'm currently working with a relatively fresh ServiceNow instance focused on core ITSM (Incidents, Requests, and basic Catalog items already live). There's still a lot of room to improve efficiency through automation and good design practices.

I’d love to hear from more experienced sysadmins and architects:

• Which automations would you prioritize first in this kind of setup?

• Any practical tips using Flow Designer, Business Rules, or Script Includes that really helped your team?

• How do you structure roles and permissions to balance control and usability without creating bottlenecks or security gaps?

I'm preparing for the CSA certification and want to apply real-world best practices from day one.

Thanks in advance for any advice or stories you’re willing to share!

[Mark Manders]

Without knowing what you already automated, we can't answer your question.

Without knowing what your company's challenges/requirements are, we can't answer your question.

Make sure you document what you do, so that in a year or 2 people still know what your BR/Flow does and what your script includes are for. Make sure developers know which script includes are there, so new functions can be added instead of new scripts created.

Roles are assigned to groups and users are assigned to groups. No exceptions. Make it impossible to assign roles directly. 

Use ACLs in the correct way. Don't script if it's not needed. Security attributes have been created for a reason.

Don't allow (too many) exceptions. Have people explain why they want something instead of just doing what is asked. Make sure you have governance in place. 

[GlideFather]

Hi,

I would say there is no general answer to your questions, as each client is unique and has specific needs and requirements.

Practical examples for FD, BR, and SI may be:
- FD: you can set pretty much anything, from approval logic to auto-closure (e.g. records without update in the last 7 days are automatically closed), depending on the conditions, FD can be triggered when some specified record is updated or created, or after a particular amount of time (after 1 hour, 1 week, 1 month, .....), the advantage of this is that you can do some magics without a single line of code, buuuut code can sometimes give you more options.

- BR: again it depends on the scenario, BR are ALWAYS triggered based on their conditions (e.g. incident is updated, user account is deactivated etc.) and then some pre-defined actions are done. It is also possible to do it without a single line of code but the options are very limited in there. 

- SI: it is just a piece of code in the server side, usually a function that is being called from another configuration. For example a user on Portal (front end) loads a form and is filling some data and there is a field to select a location, the front side "does not know" the values so it needs to retrieve these from the server and in there you can call a function written in script include from a catalog client script (front end). 

Also, different use cases you will see in a bank, in an automotive or any other company. When you are preparing for the CSA, you should be fine focusing on ITSM and ITIL.

A little help to imagine: in a company there is an electricity outage every working day at 7:03 AM, many people reported this in incident (= something is broken and I need to fix it, goal: find solution quickly as you can), when the service desk can see many incidents with the same root cause they will create a problem (= a bunch of incidents, goal: find the root cause to prevent this happening again).
During the problem investigation, an agent finds out that there is a cleaning company that unplug some cables in order to plug their vacuum cleaners and clean the office, when they are done, they put it back and everything works correctly again.
So, to fix this - you have a problem with the solution, but you will need to request a change, when the request is approved, a change record can be created (emergency, standard, normal - learn the differences).
Now, you have scheduled the change (addition, modification or removal of something - either HW or SW) to be made at specific and agreed time.

Once the change is completed - in this case it could be for example adding more sockets to the office, locking the existing ones to make it impossible unplug, or instruct the cleaning company about the impacts. 
Once all this happened, you can writhe a knowledge article about it.

So TLDR - Incident > Problem > Request (REQ-RITM-SCTASK) > Change > Knowledge.