Hello
As of today Businesses agents can’t create change as they don’t have access to the Change module by design.
So if Businesses agent need to create a Change they need a extra requester account or be change to a IT agent.
My suggestion would be that they get access same as requester’s get the end user portal.
What do you think ?
Please tag others as well if you feel this would be a good idea :)
good idea. can’t this be done via API?
I have seen a workaround - use SR to capture basic (very) details on a Change Request and then use an API call to create a Change Request.
However, if I’m not mistaken - the API does not support populating planning fields.
/Alex
good idea. can’t this be done via API?
Yes you can use as Alex (Alefre) say that use a SI and API. But that is cumbersome as you need to keep that service request updated as well.
Please like, subscribe and comment… ops wrong platform :)
I think this is a great idea. The other option is to allow limited use for Business agents to submit, view, and approve a change. Since ITSM is a team effort between business leaders, business support staff and IT they should be allowed to participate in the functions of a CAB effectively.
They do not need access to the associated assets or to edit all details but they should be able to initiate, view the change, and approve application changes (submitted by others) they may be the owner of.
yes, there’s a grey area when a Business Agent needs to be treated as a requestor…. as an Idea, ( Ihave no usecase to test it) could the an Alias of the business agent be added to Fresh, as a requestor, which would allow them to login as a requestor when needing to raise a change.
I think this is a great idea. The other option is to allow limited use for Business agents to submit, view, and approve a change. Since ITSM is a team effort between business leaders, business support staff and IT they should be allowed to participate in the functions of a CAB effectively.
They do not need access to the associated assets or to edit all details but they should be able to initiate, view the change, and approve application changes (submitted by others) they may be the owner of.
I like this. However, I think that many does not fully realize that the ITIL processes are actually ment for the entire business and not only IT.
My many years working with ITSM and ESM keeps showing me that the entire business needs help planning and performing changes, investigate why incidents happens, track candidates for improvements, keep a register on assets and deploy new ways of work or products as releases.
All of these usecases that are “true” Enterprise Service Management is surprisingly defeated by Freshservice’s ESM initiatives - a rather funny paradox if you ask me :) Especially when considering top competitors are shifting more and more towards this.
I invite other’s opinions of course and perhaps in another thread - but I wholeheartedly support this idea and really hope that Freshworks (ping
/Alex
yes, there’s a grey area when a Business Agent needs to be treated as a requestor…. as an Idea, ( Ihave no usecase to test it) could the an Alias of the business agent be added to Fresh, as a requestor, which would allow them to login as a requestor when needing to raise a change.
In this case, I have Business Agents who act as workspace admins. We do not want the workspace admins to turn on new workflows in production without approval. We want to doublecheck the work, ensure it is in the correct firing order to not impact other workflows, and ensure it is fully tested in production.
We can do this now, informally through a service request but I’d love to keep it all in the Change Module.
This feature needs to be implemented. There is absolutely no reason why business agents shouldn’t be able to create change requests.
Not a FreshWorks employee but my understanding on the Business agent option was added to allow for instances with heavy business use (but no need for asset/change/release management) to be able to have a restricted capability but cheaper agent type. Adding “features” into the agent type would likely involve some sort of cost.
It would be interesting to see if an Occasional Agent capabilities can be expanded instead to where if a business agent needs to upgrade to full IT agent they can do so for that day as needed, though after using 2 days worth (one to create change and another to present/close it to a CAB) you’re at the same cost as just having them always be an IT agent. You /could/ work around this by having them make the request to a person that then presents it to the meeting after doing a review. This practice is probably a good idea from a design/SME perspective to ensure that overall the modifications being made are good to go prior to bringing to CAB.
The point is not giving the access to the agent part of the Change module, is to be able to request a change.
A HR tool need to upgrade the system, restart a server or anything that might need a Change for.
A Business owner or Service owner for are a Business agent, as of to day they need to be upgraded to a IT agent or Occasional agent to place the Change request. Or ask someone from IT or a requester with Change access to do it.
The point is not giving the access to the agent part of the Change module, is to be able to request a change.
A HR tool need to upgrade the system, restart a server or anything that might need a Change for.
A Business owner or Service owner for are a Business agent, as of to day they need to be upgraded to a IT agent or Occasional agent to place the Change request. Or ask someone from IT or a requester with Change access to do it.
Exactly. I don’t want the Business Agents to get more IT Agent features. I just want them to be able to request changes (or in general use the support portal) like every other requester can.
Great suggestion! Giving Business Agents change request access—like requesters on the end-user portal—would streamline workflows without needing extra accounts or IT agent roles. This would improve efficiency while maintaining role-based access control.
I have seen a workaround - use SR to capture basic (very) details on a Change Request and then use an API call to create a Change Request.
However, if I’m not mistaken - the API does not support populating planning fields.
/Alex
It’s not directly called out, but I was able to solve for all of those fields. Here’s an example API body that I have. I edited out all my contents so that number fields are indicated by #####, strings are just “”, etc should be pretty self explanatory. We even have two additional/custom fields called Test plan and Post implementation review that I have included.
Endpoint
Body
{
"group_id": ######,
"priority": ######,
"impact": ######,
"status": ######,
"risk": ######,
"change_type": ######,
"subject": "",
"department_id": ######,
"description": "",
"planned_start_date": "DatetimeISO",
"planned_end_date": "DatetimeISO",
"email": "{{ticket.from_email}}",
"assets": [
{
"display_id": ######
}
],
"planning_fields": {
"reason_for_change": {
"description": ""
},
"change_impact": {
"description": ""
},
"rollout_plan": {
"description": ""
},
"backout_plan": {
"description": ""
},
"custom_fields": {
"cfp_test_plan": {
"description": ""
},
"cfp_post_implementation_review": {
"description": ""
}
}
}
}
Downside the API can’t associate the request with the change so the change manager need to work in 2 tickets to communicate with the requester.
ping
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.