Decision Tables and user role - licensing

[Tom Sienkiewicz]

Hey Everyone,

I was thinking about exposing the Decision Table Builder to some of Business stakeholders, since this is a low-code tool and I believe this would provide nice self-service capability to the Business, to be able to configure some of their logic.

The thing is, accessing Decision Tables requires the decision_table_admin role. It is marked as an "Admin" type of role in the Subscription Roles. So, would any user having that role increase the licensed users count?

Has anyone maybe considered the same/used the above approach? Has it worked for you?

Cheers,

Tom

[Laszlo Balla]

Hi Tom,

I must start with the evergreen template response: check with your ServiceNow account manager. That is alwayst the safest thing to do.

Now with that out of the way, I can share what had been my personal experiences across different customers contracts (yet, it may not be applicable to you, keep that in mind). Please don't take this as a generally applicable rule though.

• In most cases, this would indeed be a licensable role. The nature of the license, however, really depends on your available subscriptions, but the business stakeholder role would not cover it.
• If you would grant this role to the users only in a sub-production instance, you obviously don't need to worry about the licensing. However I understand that using a developer instance might be a bit of a stretch for business users. If you have (or planning to have) a citizen developer strategy, it might worth considering having a dedicated citizen developer instance in the long term, and letting the users work in AES using deployment pipelines, as they can't be bothered learning what an update set it. But this is a totally different topic now 🙂

[Tom Sienkiewicz]

Thanks for your input. Yeah, I'm also exploring the AES/Pipeline as all of that definitely fits into the low-code strategy (I don't like this term 'citizen developer' hah).

Speaking of that "citizen developer instance" - would that not simply be the dev instance? The way I see it, low-code folks might need to collab with pro developers depending on the nature of the application, so the dev instance seems like potentially a good fit? Or are there reasons not to set it up that way?

I believe Decision Tables can integrate nicely into this low-code approach, since they can be created from Flow Designer. And I hope there would be only a few users that would actually maintain those decision tables, so hopefully the licensing aspect won't be a blocker.

[Laszlo Balla]

It is totally legit to use the same instance, as long as you can keep the low-code developers (citizen or not :D) contained. Some organisations simply prefer a more federated approach with several sub-prod instances, even amongst pro-devs. There's no one size fits all (is there ever...).

Personally I think it is a good direction, especially if you have business stakeholder who are open and willing.

[Paige Duffey]

I’d echo this. A separate instance for your “citizen” (or delegated or federated) developers does not restrict your SN dev team from assisting them. But it does prevent your citizen developers from doing anything that could impact in progress dev work by your dev team. (I mean… just pulling a completely random, neeeever happened before example out like… changing something integral on the user table that prevented anyone from logging into the instance with any account…) This is especially true if you are NOT limiting those users to something like AES.