How to avoid having to log on to ServiceNow

[carlh]

I am hoping someone will point me in the right direction.   Sorry, I have no idea what the technical jargon is for this requirement.

We have multiple network domains.

1 is for "Club User" and they have access to anything "club user" has been given
permissions to and the other is our corporate network and we require users to
sign in as themselves for that as there are various permission levels based on job title or group.  

What we want to do is eliminate the requirement to log on to ServiceNow.

If the user is logged in as Club User, we want them to be able to create incident on behalf of the location.

We don't care who submitted it, just about what club it's for.

But, we also want to have it where one can log in as themselves and see the history of their personal
requests.   (Maybe make them enter their name as the requestor so we have it even though they submitted as "Club User")

Is there a way we can write an "On load" script that looks at the user and then allows access without having to log on?

This would make it a more seamless user experience for our organization and may help me to get more users "using".

Can anyone help me?   Even wording it properly would be a good start but I hope to get some ideas too!

Thanks!

Carl

[Chuck Tomasi]

Hi Carl,

You might consider making a service portal with certain elements publicly available. Other bits might require you to create public pages.

I heard a similar request once where someone said "I don't want people to have to login, but they should be able to check their status of things they requested." Which makes no sense to me because if the system cannot tell the difference between you and me when we're creating records, how does it know what to display to you and what to display to me? This sounds like a similar request only you're allowing them to now login and check the status, so you'd have a bunch of records created anonymously and somehow after I login, it's supposed to know that really belongs to me? I'm a bit confused on this one.

Short answer - yes, you can submit things anonymously - it's how things like password reset work. Long answer, once it's 'unowned', you need some sort of identifier to assign it ownership later.

[carlh]

Thanks Chuck. Yes! I was also confused at first. It's the best of both worlds. Our current networks are set up the same way. We track things by club first, then people.

I mentioned in my post that I would have the anonymous user enter their name or user info on a reference field on the form so we can tie it back to the user that way. We can have a business rule populate change the requestor field before insert.

I'd like to go further on this if possible. Sounds like we can do what we're looking for but I still am not sure what sort of effort it would take.

We have yet to make things public (wouldn't want to make it fully public, still need to be on one of our domains at least as club user)

[Chuck Tomasi]

Thanks for the clarification Carl.

Two things I would look at:

Service Portal (provides a nice consumer like experience, but takes some work to plan and build.)

http://wiki.servicenow.com/index.php?title=Making_a_Page_Public

Public pages to expose certain bits of the system to the public without credentials. The tricky part with these is making sure the public can read things like the User table so they can pick their own name. ACLs can fix that, but carefully consider what it means to have your user list made public!

[carlh]

Rather than publicly exposing our users or anything, I'm thinking we can use "Club User" as the user. I'm thinking I want it to sign in with a script as Club User.

Example, user in the club finds a broken phone on a sales desk and needs it replaced. It's not property of the user, just an item in the club they work in.

So from our intranet, the user would click a link and that would take them to the User Portal and auto sign them in as "Club User"

They create the incident as user "Club User" and I will make them fill out the fields needed to identify and make them the owner on insert.

The idea is to not make them log on to another application in order to do work for their club.