Clarifying end user roles, access and licenses

[mitzaka]

Hi, I have a general question about a specific scenario regarding effective usage of UI forms taking into consideration ACLs and roles. I know there is some articles out there for similar topics but still I am not sure there is a satisfactory answer, so here goes:

Imagine the case - let's say we are talking about an instance with a very large number of end users, with large portions of the work being handled round-the-globe as there is a requirement for multiple people to be able to see and comment on multiple tickets (here by tickets I am referring to incidents and requested items mainly). Pretty much the scenario of every large company out there:)

Out of the box, there are several ServiceNow's rules which we are taking into account when we talk about no-role users:

1. Only the person who opened the ticket is able to modify it

2. As far as visibility, apart from the creator and the the people who are on the watch list are able to see the ticket

3. Any modification of the ticket can be done only by a user who has a role (=license)

Following are my questions to this scenario:

A) Regarding visibility, placing a no-role read ACL on the ticket table would make the records searchable and read-only visible to users. Am I right to think this is a valid and legal approach?

B) If a requirement is for end users to be able only to add customer comments to tickets, would that still be a modification of the ticket? Purely from a logical point of view, this should not be a modification of the ticket as no attribute is being changed, it's only the comments added. Just like adding comments via reply to an email message but using the tool instead, which in the end is what it's all about.

So again, am I right to think that allowing no-role end users to enter ONLY customer comments in tickets is a valid and legal approach?

[mitzaka]

Okay, here come the news from the source:) I was on the phone with a ServiceNow representative and explained my case. Here is the written answer to that, I think it's clear now, at least for me.

1) You can create an ACL for the incident (any task) table, which is granting the read access for all users with no roles. It is not illegal, and there is no violation of the licences you have, however, you will have to be aware of all the consequences as a result of that. Whenever adding a new ACL, or modifying the existing ones, it is your responsibility to test the platform afterwards, and verify that no security issues occurred.

2) Regarding the comments and the work_notes fields, they are, like all other fields, fields on the task table. Like all other fields, they require write ACLs in order to update their content. Again, as I already mentioned above, we do not limit you with the amount or type of configuration you can perform to the OOB ACLs, however, you will have to test the platform afterwards, to see that there are no security issues.

As long as the process flow is not changed by the customer interaction, this is OK with no need to use a license. After all, like I said in the beginning we are talking about adding comments here, not modifying the attributes or workflow of the ticket.

Cheers!

[vant]

If I had a question for support representatives about licenses, at least in the past, they would say I should talk to my account executive as they wouldn't know the terms of the contract. During an audit experience, they had a special individual audit the instance live. Good luck!

[mitzaka]

Yes, we also talked to our sales representative and he answered that any change on any field from a non-licensed user who is not the creator of the ticket would require a license. However, I still think that this is not a reasonable licensing approach. I mean specifically for comments - you are adding a comment, you are not changing any workflow, process or fulfilling anything, we are still confused to accept and comprehend that this is considered something which requires a role/license. We are talking about end users, who just are round the globe and would like to have transparency over what is going on with a ticket. This is it.

How have you solved this case in your instances? I am curious do people live with those restrictions or they have some workaround of this - legal of course I mean. Technically it's clear that you can modify ACLs and do whatever you like.

Also, in my opinion what ServiceNow should be thinking of doing is to provide some kind of a light-user license for such cases. Something which would be the vehicle of positioning your comments and getting input into tickets at a much lower licensing cost.

[mitzaka]

Interesting - the above is what I officially received from ServiceNow support when I opened a HI ticket on this. However, our sales representative denies this saying that any modification of any field requires a license, if the user is not the creator. Odd..I think ServiceNow should clear this out for themselves and be consistent on this.

[elfanne1]

We are having the same discussion open with our ServiceNow sales representative.

The use case for us:

1. End User reports an incident via self-service

2. Another End User is having an similar issue and wants to know, if other users are facing the same > but not able to do it, because of non-licensed users aren't able to view incidents from other users. (rolling eyes)

IF they could see already reported issues by other users, they could just add comments there (example: I'm having the same, it's not an issue just with one user) and add themselves to the watch list, we could save a lot of time, money and extra (old-fashioned administrative) work in our business side (customers/end users) as well as in company ICT (support team/licensed users).

Just don't get it.... incidents are data/information, which is an asset and should be owned by the company. Now we aren't able to use this 'asset' in best possible way.

I have to say, that I'm very disappointed of this feature.