My team can't do any type of scripting in our SAND Instance
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Hello,
We purchased a 'SAND' instance about 4 years ago. It worked great for about a year. We used it as a secondary development instance, going between DEV and SAND for development. 3 years ago, we cloned down from production to all our sub instances with the same clone profile. We were able to script in all sub instances except for our SAND instance. I put in a support case but was told it was our network causing issues even though all other instances worked perfectly. I was told to do a 'zBoot' on the instance and did so. This caused me to have to redo everything on the instance. It was actually like OOB, i.e., LDAP, SSO, etc, had to be reconfigured. Finally getting that done, we had the same issue. When i say we can't script on the instance, i mean we can't create and save a fix script, business rule, scheduled script, etc. I can't even modify a script and save it. I get this error.
"The webpage at https://<instance>.service-now.com/sysauto_script.do might be temporarily down or it may have moved permanently to a new web address". I was told it was our network which makes no sense because all other instances work great with no issues. Sure, I could think of it being a firewall on our side, cyber blocking it or something, but it worked for over a year. I was then told to use the default OOB clone profile to clone over the SAND instance. Same results. Long story short, we finally had the support team to blow up the instance all together, then several weeks later, they stood up a new sand instance for us, sand2. worked great for a week. cloned down and then we had the same issue. I think it is just a cooincident that the instance had issues after the clone. This has been going on for over 3 years. For Real!. Have any of you heard of this at all?
Today, support did a change for 'Role Recalculation' thinking it was role related. Same thing after the change.
Any suggestions would be greatly appreciated
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Hi @John Johnson,
check this group >>> Conditional Script Writer
https://yourinstance.service-now.com/nav_to.do?uri=sys_user_group.do?sys_id=5ee74940b70022108d4406dd1e11a918
eventually role >>> snc_required_script_writer_permission
https://yourinstance.service-now.com/nav_to.do?uri=sys_user_role.do?sys_id=af99d5310be312105bf96e1ef777b2b4
Worked for me some time ago, let me know if that helped you..
No AI was used in the writing of this post. Pure #GlideFather only
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Thanks for your response! Diggin deep into your explanation and info on the role for 'conditional script writer' it looks like that only blocks freeform scripting in the BG-'Scripts Background'. 'sys.scripts.modern.do'. This is not my issue. I can write and run a freeform script in the scripts background editor with or without the mentioned role. My problem is that i can't create, modify and save, or run any scripts at all. i.e. fix script, background script, UI Script, etc. Thoughts?
(I did test out your theory in depth and appreciate your input!)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Ah okay, I misunderstood.. could you give any example of what kind of script in particular?
Also, is it for all the users or just some?
No AI was used in the writing of this post. Pure #GlideFather only
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Sounds like a role or permission issue rather than a platform bug. I’ve run into this in ServiceNow SAND environments where scripting is deliberately locked down. Admin rights, scoped app restrictions, or update set controls can block even basic scripts. Checking system roles, ACLs, and whether the instance is set to “no-code” mode usually clears things up fast once the right owner is involved.
