最近の検索
最近の検索はありません

Matt Owens
参加日2021年4月15日
·
前回のアクティビティ2023年5月08日
Curious person who dabbles in technical fields. Long time user of Zendesk.
フォロー中
0
フォロワー
0
合計アクティビティ
29
投票
6
受信登録
13
アクティビティの概要
バッジ
記事
投稿
コミュニティへのコメント
記事へのコメント
アクティビティの概要
さんの最近のアクティビティ Matt Owens
Matt Owensさんがコメントを作成しました:
Matt Owensさんがコメントを作成しました:
I'd like to also add another use case for the team.
Currently we have an integration with Workday that leverages the Create or Update endpoint and external ID for any changes. Mostly we have user fields that hold information such as location, cost center, employee type, etc.
An issue we have is when a user is converted from Contractor to Full Time. We have different email domains, one being @companycontractors.com and the other being @company.com. While we are able to add the new email (conversions typically are contract to FTE, rare cases reversed) it's not set as the new primary email. There is a grace period before we remove access to the old domain. In some situations employees are submitting tickets without seeing any notifications back as the email is secondary.
Ideally we'd like to have the option in the Create or Update endpoint to specify Primary Identity when doing these calls.
Best,
Matt
コメントを表示 · 投稿日時:2022年11月18日 · Matt Owens
0
フォロワー
0
投票
0
コメント
Matt Owensさんがコメントを作成しました:
Hey Eric,
Currently we implemented the above use case, and are indeed blocked because there is no way to have anonymously read objects. The authenticated experience is great, but the experience would be next level with anonymous endpoints.
I've also shared feedback that this will need to be in place if there is any hope to have Look-Up fields be end-user editable for un-authenticated support contacts leveraging objects.
コメントを表示 · 投稿日時:2022年11月17日 · Matt Owens
0
フォロワー
0
投票
0
コメント
Matt Owensさんがコメントを作成しました:
Hey Jon,
Do you already have the object associated to the User object with a relationship? If so you'd just need to use the List Related Object Records endpoint with the User ID.
function userKits(client, id) {
var kits = {
url: '/api/sunshine/objects/records/zen:user:' + id + '/related/{relationship_type}',
type:'GET',
dataType: 'json',
};
From there you just parse and display the data in the object record you want to show.
If you don't yet have the user associated to an object record, then you'd need to set up your relationship type, and then have a mechanism to associate the two.
Matt
コメントを表示 · 投稿日時:2021年6月21日 · Matt Owens
0
フォロワー
2
投票
0
コメント
Matt Owensさんが投稿を作成しました:
Hey team,
Wanted to see about the feasibility of having an anonymous read-only permission on some of our object types? We had the following use case that we are trying to support.
Use Case: User scans QR code that has URL which contains the Object ID in the params. On the HC site we fill values from the object to hidden fields on the ticket. User then submits information about the location (think bathroom, needs cleaning). The object look-up should be allowed anonymously as the user isn't required to be signed in to submit a ticket via QR scan.
Currently we have tested 90% of this, but it appears we'd have to store some generic end-user credentials to make the call. Ideally I'd like to have an option for anonymous read-only for this, or possibly for catalog items in the future. Objects are currently updated via integration to another service, so we want to preserve the URL as opposed to having to update the URL & QR with params when values/names change.
投稿日時:2021年6月14日 · Matt Owens
2
フォロワー
5
投票
8
コメント
Matt Owensさんがコメントを作成しました:
Thank you @... for the additional context!
Also adding in a vote for this, we have some confirmation checkboxes that would greatly benefit from allowing line breaks and bolding. Looks like URLs auto-format to href links, so maybe opening the scope of the HTML used would be super helpful on our end.
コメントを表示 · 投稿日時:2020年8月03日 · Matt Owens
0
フォロワー
1
投票
0
コメント
Matt Owensさんがコメントを作成しました:
Hey Zendesk Team,
Wanted to check on this, I found a similar conversation from 5 years ago in the About Ticket Fields thread with the following comment.
There were two links included, both are dead now.
Feature Request: HTML in Ticket Field Descriptions as well as Customizing Ticket Field Descriptions With HTML.
Any insight on if the feature was closed as "Won't Do" or if there is a way to get around the HTML scrubbers, of we could get that article published again as "use at own risk"?
コメントを表示 · 投稿日時:2020年8月03日 · Matt Owens
0
フォロワー
1
投票
0
コメント