Jorge Vargas Telles

• What is the problem?

We want to be able to differentiate between Prod and SadBox accounts.

• Why is it a problem?

We want to avoid users confusing the environment and changing settings on the incorrect one because they're an exact match.

• How do you solve the problem today?

 We need to check the settings every time we want to do a change just to confirm which environment we use, but non-admin users can't do this so they won't know/confirm which environment they are at.

• How would you ideally solve the problem?

1. Change the banner color
2. Or add a Label on the top saying "SandBox"

• How big is the problem (business impact, frequency of impact, who is impacted)

Low priority but it would be good to avoid confusions/problems in the future.

• What is the problem?

Right now if we want to restrict who can edit certain fields we can only restrict this to "Admin" users. This is problematic because we are then provisioning far too many people with Admin access.

• Why is it a problem?

We don't want to make every user who needs access to specific admin-only fields an Admin, as of now we don't have a choice when that scenario happens.

• How do you solve the problem today?

Give unnecessary Admin access to some users.

• How would you ideally solve the problem?

Add the ability to restrict custom fields so that way they can only be edited/filled out by a specific role that we created

• How big is the problem (business impact, frequency of impact, who is impacted)

This is important as we have to many admins in the system and the expectation is to have only 1 or 2, but this system limitation won't allow us that.

• What is the problem?

We can't enable SSO to Zendesk Sell without impacting our others Zendesk Products as well.

• Why is it a problem?

This is a InfoSec requirement in order to use the system.

• How do you solve the problem today?

N/A. We can't enable this

• How would you ideally solve the problem?

By having Zendesk Sell and other Zendesk products instances not connected so we can implement SSO only to Zendesk Sell.

• How big is the problem (business impact, frequency of impact, who is impacted)

Is important as we need this implement due Audits.

• What is the problem?

ZD sell is considered an in-scope SOX system for us and thus our auditors require that we receive/review a SOC Report.

• Why is it a problem?

We need this for Audits

• How do you solve the problem today?

Manually

• How would you ideally solve the problem?

Short term: Obtain at least a SOC 2 Type 2 Report coverage for ZS, Zendesk is already covered by it but Zendesk Sell specifically is not

Obtain a SOC 1 Type 2 Report (covering at least 9 months of the year) coverage for Zendesk Sell

• How big is the problem (business impact, frequency of impact, who is impacted)

Is high for us as we need this in order to get green light for our audits.

• What is the problem?

We have no way to track changes on any of these settings in Zendesk Sell.

1. Creation/Update Field Requirement rules.

2. Track Admin-only changes to custom fields.

3. Creation/Removal of API Tokens.

4. Changing SSO/Auth configuration.

5. Which user gave access, removed or deactivated another user.

• Why is it a problem?

We need to be able to track system changes done and who performed that action, due audits we have.

• How do you solve the problem today?

We take screenshots on a monthly basis on the system.

• How would you ideally solve the problem?

Track any user action done within the system, specially admin settings related ones using the FireHose API.

All of these should include:

A. Who did the action.

B. Action performed.

C. Timestamp of when the action was done.

• How big is the problem (business impact, frequency of impact, who is impacted)

Is critical for our business so we can score well on our audits.

• What is the problem?

We submitted this ticket where we confirmed we're not receiving the user_id for every interaction done within the system

• Why is it a problem?

This is very important for us as due Audit, we need to know who's the user who performed an action within the system.

• How do you solve the problem today?

N/A. We rely on the logs which don't have this data.

• How would you ideally solve the problem?

Properly implement this beta feature because as stated by one of the last responses on the ticket, as this is a beta feature the user data can be lost within the ZS Pipeline

• How big is the problem (business impact, frequency of impact, who is impacted)

This is critical for Audits, we need this feature as soon as possible.

• What is the problem?

As of today we can't track what are the current permissions and to who they're assigned to, either roles or specific users.

• Why is it a problem?

This information is needed for InfoSec purposes.

• How do you solve the problem today?

We have to take screenshots off every user permissions. 

• How would you ideally solve the problem?

Add this information in the API so we can generate reports and query data.

• How big is the problem (business impact, frequency of impact, who is impacted)

Is big, we need this for Audits 

We would like that:

Short term Ask	Long term Ask
Add Permissions to the Rest or Core API to pull the user data of them just like we do for all the other user details.	Add this to fireHose API as well so we can also track this information with the corresponding timestamp of when a change happened with a permission