Hello, we are in the process of finalizing setting up FreshService for our organization and we’ve come across an issue with the Requestor field in the Admin-Field Manager-Form Fields section for tickets. It does not appear to be editable or disable-able, which is something we are wanting to do as users are inserting random emails and other users’ emails. This is a problem because we lose track of who and what department has submitted tickets, which is the main reason we are implementing a ticketing system. We’ve spent 2 business days researching this field, both in the FreshService guides, community, and Google, without any luck. There also does not appear to be any way to edit the HTML of the field to simply hide it.
Does anyone have any suggestions or methods to disable or remove this field? We are very happy with FreshService through the trial but this issue only just surfaced as we are rolling our to the larger organization. It is disappointing that it is not editable or removable, and there is no way to disable users from changing it, to the point we might switch ITSM. It doesn’t seem professional to tell our organization to not touch a field in a brand new software because it can cause inaccuracies with ticketing and analytics.
Page 1 / 1
Hello @Manning Park, your research has proven true. The Requester field is not editable and there is no way to hide the field.
Perhaps you could add some context in how you are using Freshservice. Who are your “Requesters”? How do they raise incidents and service requests? Are you using a “Support Email Address”?
When you refer to “users are inserting random emails and other users’ emails”, who are the “users”? Are they freshservice agents?
Some things you can do to help alleviate excessive creation of “Requesters” is to use domain whitelisting to prevent non-whitelisted domain email addresses from being able to create tickets. You could have all users submit tickets via email to your support email address. Use Single Sign On or some form of authentication so that users have to “Log In” to submit tickets via your support portal.
If it is agents that are generating requesters when creating tickets, you will need to tackle that with training. You can restrict permissions to be able to edit requester information but I was not able to find a way to hide the ability to create a new requester from the New Ticket screen.
I will say that one of the more challenging things we have had to deal with is the managing of user data in freshservice.
Perhaps some of our other community members have some ideas to help. I wouldn’t abandon freshservice if you can help it, its a great product in my opinion. Best of luck, take care!
Hello,
Ok that isn’t good. Our requestors are non-agents submitting tickets and service requests via portal, which is what they have been using before. We’ve already toyed with sending via email but it did not prove to be the best fit for our use. Requestors/users are any non-agent employee of the organization, they submit the tickets.
We have already disabled all logins other than SSO, disabled the setup accounts option, and we’ve allow only our domain to be able to login and submit tickets to prevent external individuals from accessing our portal.
Our agents are fully trained on FreshService, we haven’t had any issues there. It’s just the requestor field when a non-agent submits a ticket that is our issue.
I believe there is a way to hide this but that has consequences that for example a manager couldn’t put the request in on behalf of someone else. We ran into a scenario that managers were using this during onboarding events and would but the future employees potential company email as the user to request services before the user was created or started.
One option is you could hide the requested for page and on the main service request page put a custom field(s) to capture the requested for and/or requested on behalf of with the All Users object. However I’ve found an issue with doing this in that when the user is disabled or removed in the future their names disappear from these boxes. So if you are auditing in the future , you will see a service request issued and that information is blank. I’ve worked around that by entering a private note or a task with the information so any user fields that could disappear in the future are still visible somewhere in the request.
We’ve had the same issue come up as well where another email was inputted where that associated account was not set up yet, or the email was was inputted was not spelt correctly, and it caused some issues.
We’ll see if we can try that and see if we can work with that data.
To confirm, the requester field can be hidden using code. We had a similar concern and so opted to hide it completely.
Our experience is that staff are not missing this field. When it comes to submitting “Issues” specifically on behalf of someone else, they will simply fill in the context in the description. It is at the agent's discretion if updating the form with a different requester/requested_for will be beneficial for tracking/historical purposes. We have found that the staff submitting ticket is the more reliable contact point which is more important for us, though I appreciate every organization is different.
Best of luck with the implementation. FreshService has been a successful tool for us but not without its quirks. It does, however, have room for creative workarounds and there is a great community who are willing to help.
@MichaelS24 Can you share the code and where you placed it on the service portal customization? We have issues where people are spelling names wrong in email addresses and it is auto-creating requestors. We want to limit it to only those who are already requestors.
Suggested Workarounds
Custom Permissions via Roles:
In FreshService, you can set custom roles and permissions. If possible, limit the ability to modify the Requestor field to certain roles, such as admins or team leads, and restrict standard users from accessing or changing it. This can help prevent unauthorized changes to the field, ensuring the correct requestor information is preserved.
User Education and Training:
Since removing the field entirely isn’t an option, providing a brief orientation or guidelines to users can help. In this training, explain that using accurate requestor information is essential to ensure proper tracking and departmental accountability, especially for issues related to pain relief for legs or other critical requests. You could also provide an FAQ or a tooltip on how to properly fill out the form.
Ticket Automation Rules:
If FreshService allows automation rules for fields, set up a workflow or automation to alert the support team whenever the Requestor field is filled with an unverified or incorrect email. This way, you can identify and correct errors as they occur, preserving ticket accuracy and tracking.
Contact FreshService Support for Customization Options:
Although you might have done some extensive searching, contacting FreshService support directly may reveal hidden options or customization through the API. Sometimes, support teams can provide solutions or even enable specific features not readily accessible in the front-end options.
Integrate a Custom Form:
Consider creating a custom form that users fill out externally, with only essential fields like their department and contact information. This form can be configured to automatically create tickets in FreshService, bypassing the default Requestor field and reducing the risk of data errors.
Hi Shannon,
Please see image below:
You can find this under Service Desk Rebranding > Support Portal Customisation.
@MichaelS24
Is the code for all Service Requests/Submission of a ticket, or can you pick and choose what it applies to?
This should just hide the field under the “Report an Issue” section. Service Requests will still honour the service catalogue item fields you create.
