Reports, should they be created in production?

carlh · ‎04-01-2016

Hi All,

We're new to Enterprise and have implemented some processes and procedures for how we want to handle "writing to production". I have the admin role on our Dev/Test environment (1 instance) and no role on Production so I can't even see a report. Does it make sense that I should create reports in dev/test and then move them in to production via update set? If so, does anyone have a good step by step to get everything moved together? I moved a dashboard, then realized the reports and gauges hadn't been moved so I loaded those via XML. Still not working. My argument is that they should be created in production so I am hoping to get support/ammo or advice from the communit.

Thank you all!

Carl

richelle_pivec · ‎04-05-2016

I was actually hired to be the Admin for the database. Shortly after I started I took my ServiceNow System Administrator exam. If you are a certified ServiceNow System Administrator, I'd say you have a strong case right there.

When we hired my second teammate, we didn't give him the Admin role for the first few months until he had a feel for what he would and wouldn't be doing in there.

Generally speaking, we have a process for what things can be done directly in Prod and what things need to go through a Change request (with update sets and manager approval). I adhere to those standards because it is part of my job to adhere to them. I also helped make some of those standards by knowledge I gained here and in the wiki about SN Best Practices. For example, things that can be done in an update set usually should be done in one. Updating a record (user record or task or on-call calendar) are things that can be done directly in Prod. We do reports in Prod because they don't actually effect the records or the infrastructure...just pulling data together in a view. I limit who can save Global reports so they don't clutter things up for everyone, but allow itil users to make their own reports and save them as they want. They can't make gauges, but after I make a gauge and migrate it to prod, they can use it for their custom dashboards...

My answer as to who should be the Admin would be the person (or persons) who knows the most about how SN is built and how to build for it. I would say if there is a process in place for what things will be done directly in Prod and what won't and if you are the most qualified person to do (and validate) those thing, you should be the Admin...

Hope that's helpful,

Richelle

View solution in original post

carlh · ‎04-05-2016

Thank you again. How did you determine you wanted to operate this way rather than giving no access to developers/a ServiceNow Admin in production? Technically, we do not have a Trained ServiceNow admin on our Systems Admin team. I put in a deployment and then stand over them while they deploy so I can tell them what to do.

Is there a limitation you've identified that forced you to decide to give admin access? That's what I am looking for. I need to present a strong case to get my access or I need to conform and figure it out if there is no good reason or limitation that I can identify to force it.

richelle_pivec · ‎04-05-2016

I was actually hired to be the Admin for the database. Shortly after I started I took my ServiceNow System Administrator exam. If you are a certified ServiceNow System Administrator, I'd say you have a strong case right there.

When we hired my second teammate, we didn't give him the Admin role for the first few months until he had a feel for what he would and wouldn't be doing in there.

Generally speaking, we have a process for what things can be done directly in Prod and what things need to go through a Change request (with update sets and manager approval). I adhere to those standards because it is part of my job to adhere to them. I also helped make some of those standards by knowledge I gained here and in the wiki about SN Best Practices. For example, things that can be done in an update set usually should be done in one. Updating a record (user record or task or on-call calendar) are things that can be done directly in Prod. We do reports in Prod because they don't actually effect the records or the infrastructure...just pulling data together in a view. I limit who can save Global reports so they don't clutter things up for everyone, but allow itil users to make their own reports and save them as they want. They can't make gauges, but after I make a gauge and migrate it to prod, they can use it for their custom dashboards...

My answer as to who should be the Admin would be the person (or persons) who knows the most about how SN is built and how to build for it. I would say if there is a process in place for what things will be done directly in Prod and what won't and if you are the most qualified person to do (and validate) those thing, you should be the Admin...

Hope that's helpful,

Richelle