Allow Public Requestor on Form

We are creating tickets from IvyQuantum Live Chats using the API, but when the email is not matched, the Requestor is blank.  Is there a way to allow public requestors and enter the contact info as read only without creating an active service in the service Catalog?

 

Similar to this option on a Service:

Requestor Matching Mode Hide Help for Requestor Matching Mode

When a public ticket is submitted, the Email Address field may be used to match the public user to an existing person in the system. This matching, if enabled, will use a waterfall (fall out) method in the following order:
  1. Primary Email Address
  2. Alert/Notification Email Address
  3. Alternate Email Address
Asked by Scott Cory on Mon 8/28/23 12:12 PM Last edited Mon 8/28/23 12:12 PM
Sign In to leave feedback or contribute an answer

Answer (1)

This answer has been marked as the accepted answer
Mark Sayers Mon 8/28/23 1:24 PM

I think the API would have to be collecting info for the Requestor Name and have set the flag to True for AllowRequestorCreation on this endpoint: https://yourTDXdomain/TDWebApi/api/{appId}/tickets?EnableNotifyReviewer={EnableNotifyReviewer}&NotifyRequestor={NotifyRequestor}&NotifyResponsible={NotifyResponsible}&AllowRequestorCreation={AllowRequestorCreation}&applyDefaults={applyDefaults}

Are you setting that to True currently?

Sincerely,
Mark Sayers
Sr Support Consultant, CS

No feedback
We currently do not have any of those ? options on the the endpoint URL. For non-Chico State email address, we do want to allow Requestor creation, but we do not want it to create a user account. Will that be possible with:

https://yourTDXdomain/TDWebApi/api/{appId}/tickets?NotifyRequestor=true&NotifyResponsible=true&AllowRequestorCreation=true - Scott Cory Mon 8/28/23 1:30 PM
When you are creating tickets via the API, you *are* using the POST https://yourTDXdomain/TDWebApi/api/{appId}/tickets?EnableNotifyReviewer={EnableNotifyReviewer}&NotifyRequestor={NotifyRequestor}&NotifyResponsible={NotifyResponsible}&AllowRequestorCreation={AllowRequestorCreation}&applyDefaults={applyDefaults} endpoint, even if you aren't including all of those additional options after the "/tickets" part of the URL.

Just include them as needed to utilize them. - Mark Sayers Mon 8/28/23 2:10 PM
Thanks Mark, I do realize we are using that endpoint. My concern is we do not want it to create a user account. Will "AllowRequestorCreation=true "create a read only requestor without creating a user account? - Scott Cory Mon 8/28/23 2:13 PM
Hmm, no actually it will not now that I re-think about it. It would create a Customer record for them which isn't what you seem to be wanting. Still, if you *are* collecting values that you can pass for the RequestorFirstName, RequestorLastName, and RequestorEmail (and possibly also RequestorName which would end up being first name and last name passed together), it should create as a text-only requestor.

Just keep in mind that workflows can't be applied to tickets that only hold a text-only requestor value. - Mark Sayers Mon 8/28/23 2:18 PM