Question

Requestor Field Removeal or Disable

  • 3 October 2022
  • 5 replies
  • 552 views

Badge

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.


5 replies

Userlevel 7
Badge +16

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!

Badge

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. 

Userlevel 5
Badge +8

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.

Badge

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. 

 

Userlevel 3
Badge +4

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.

Reply