
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>ITSM Toolset Governance/Permissions</title>
<link>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692236</link>
<description></description>
<lastBuildDate>Sat, 6 Jun 2026 18:50:43 GMT</lastBuildDate>
<pubDate>Tue, 26 Apr 2022 14:45:04 GMT</pubDate>
<copyright>Copyright &#xA9; 2022 itSMF UK</copyright>
<atom:link href="https://itsmfuk.site-ym.com/forums/topic_rss.asp?id=1692236" rel="self" type="application/rss+xml"></atom:link>
<item>
<title>ITSM Toolset Governance/Permissions</title>
<link>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692236</link>
<guid>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692236</guid>
<description><![CDATA[<p>Hi,&nbsp;</p><p>I am interested to understand who you grant permissions to in your ITSM toolset?&nbsp;<br /></p><p>We currently have a very loose model of which as product owner I would like to refine after understanding the need to have certain permission sets across the board however I equally don't wish to hinder service and the change will be potentially uncomfortable for our Service Desk who previously have had free rein and full admin rights.&nbsp;</p><p>If you are willing to share I am keen to understand:</p><p>- Who has access to make changes to your toolset and what are they permitted to do on their own? ie, add/amend categories/services, create forms, amend processes, set up and change Email AutoLogging.</p><p>- How do you govern/record changes to your toolset such as new categories or forms?&nbsp;&nbsp;</p><p>Appreciate any thoughts and input.</p><p>Thanks&nbsp;</p><p>Jakki</p>]]></description>
<pubDate>Mon, 25 Apr 2022 09:52:29 GMT</pubDate>
</item>
<item>
<title></title>
<link>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692397</link>
<guid>https://itsmfuk.site-ym.com/forums/posts.aspx?topic=1692397</guid>
<description><![CDATA[A few quick thoughts, Jakki. There is way more to consider than I can type here. Most organisations will limit admin access to the tool.  To use one of your examples; Your problem manager will have 'kittens' if they try to do incident matching on constantly changing categories not to mention trying to train new service desk and support analysts. If you've got a service structure (even a rudimentary one) then a couple of workshops ought to be all you need to thrash out a category structure.  Make the change process for the tool easy to access but ensure rationales for changes are clear and that those who want (need) to make changes are trained in using the process.  What can they do themselves?  A lot will depend on how configurable the tool is and the experience you want to create.  For example auto reply message are great for satisfying SLAs but garbage for CX as people typically don't like receiving canned messages.  So I think I'm trying to say.  It depends on a multitude of factors.  Happy to chat more.  Barry Corless CGI and itSMF UK Northern Region Chair        ]]></description>
<pubDate>Tue, 26 Apr 2022 15:45:04 GMT</pubDate>
</item>
</channel>
</rss>
