Admin & Settings Ideas

patrickfordey

In Spring 16 Salesforce introduced the ability to run Apex after a Sandbox refresh https://releasenotes.docs.salesforce.com/en-us/spring16/release-notes/rn_deployment_sandbox_postcopy_script.htm At this time it is not possible to programmatically update Zuora api settings in Salesforce so you cannot update the settings post refresh using the above functionality. Allowing access to the settings that control the API access would allow users to have their sandboxes automatically update themselves to point at a non production Zuora instance on refresh rather than needing it to be a manual step.

kcavanaugh

We are working with our ops team to reduce the number of manual account updates that their team has to perform, particularly related to editing Contacts or adding e-mails to the 'Additional E-mails' text box. Our hope was to create a specific profile for our Collections team to allow them to make changes to these fields. After looking at potential options, it seems that both Contact edits and 'Additional Email' edits are both grouped under the 'Modify Account' permission that also give access to ANY other field on an account level. Some of the custom Account fields we have created have end user provisioning impact, so from an audit perspective we cannot grant access to these users to edit all fields. I would like to request added functionality to be able to separate the permissions to edit contacts/addtl e-mail text box from the full 'Modify Account' permission set. This would be a big help to the efficiency of their team.

tobiax

I would like to suggest that the API be extended to handle setting up the Connection Settings in SFDC for Zuora and Zuora 360 -- currently only available via UI. This is the current process. https://knowledgecenter.zuora.com/CA_Commerce/C_Zuora_Quotes/CB_Zuora_Quotes_Configuration_Settings/A_Zuora_Connection_Settings This would be highly useful in general, but particularly for SandboxPostCopy - https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_interface_System_SandboxPostCopy.htm

martinp123

The Zuora Quotes managed Salesforce package currently does not expose programatic access to the API URL/username/password. This means that when we create a fresh dev sandbox in Salesforce from production instance, the live API credentials make it to the dev sandbox. This is not cool. Salesforce provides a mechanism for automatically running an APEX class after sandbox creation where these API connection details could be changed. But at the moment these connection details cannot be changed from within APEX. I suggest you allow for setting these three values (but never getting them) via few new methods in the NamespaceUtil class. We already have setters like setPackageInstallStatus() in there. That way we can add this to our RunAfterSandboxCreation APEX class which would point our fresh dev Salesforce sandboxes to our dev sandbox in Zuora.

Nigel · ‎08-10-2018

(See https://community.zuora.com/t5/Release-Notifications/Zuora-Application-Release-230-August-2018/ba-p/24651 for context) Currently releases are given to happen over a range of datas. There's no easy way to tell which release an instance is on please. Please could a field be added to the Tenant Profile in Admin setup that gives the currently running version - that way we'll know when the release has happened, and can tell the difference from sandbox and production environments.

yuliya_papl · ‎05-28-2018

Currently on the User account level we see the creation date only. For tracking and audit purposses would be great to have user account modification and deactivation dates.

Kenta · ‎06-28-2018

In the Notification Framework, an Event Trigger can compare old and new values on a given field (e.g. Invoice.Status and Invoice.Status_old). We would like for the subsequent callout built on the trigger to be able to reference this information This would allow an external system to hold the business logic of determining actions based on the combination of the old/new values

Zuora-Support · ‎01-13-2016

Feature Request: Require Audit Trail Status: under evaluation Reference Number: DE5826/PMT-876 Business Need: There are business requirements that are looking for the ability to have an audit trail for all fields and records. The requirement is to have an audit trail on all - Account fields (including all custom fields) - Subscription Fields (including all custom fields) - Contact Address Fields (including all custom fields) - Settings changes - Users' actions

Yoshihisa · ‎08-27-2018

We got a request that the function to get notification history by Customer Account or Billing Batch is needed. Following improvements have to be made. In "Email History"("Setup Profiles, Notifications and Email Templates" > "Notification History" > "Email History"), it is needed to have filters "Customer Account" and "Billing Batch" so users can know which "Customer Account" or which "Billing Batch" of a "Customer Account" the notification was sent to. Also it is need to have a filter "Result" to get only "Failed" ones or "OK" ones. In Notification History API in the link below, it is needed to have "Customer Account" and "Billing Batch" in the Response. https://knowledgecenter.zuora.com/DC_Developers/C_REST_API/B_REST_API_reference/Notification_History/Get_Email_Notification_Histories

rdeloach · ‎01-21-2016

It would be most helpful to be able to export a tenant configuration to a file, like meta-data or similar, and have the ability to import it into a tenant. There are 2 use cases for this: first, to back up and archive configurations to satisfy auditor requests to validate no unapproved configurations have changed. Second, in ensuring environment integrity in API Sandboxes or Services tenants to your source/production tenant.

gelaimr · ‎03-22-2018

Use Case: When creating Notification Definition, we can only set one CommunicationProfileID at a time. it is a bit of task to create definition individually when a tenant has several Communication Profiles to manage and can this also result in a profile being accidentally missed.

zachmeyer · ‎12-04-2017

We would like the ability to pass parameters into the Callout Notification BaseURL. The URL is currently static. For example, instead of a hard coded URL like this: https://mywebsite.com/zuora/account We would like something like this: https://mywebsite.com/zuora/{AccountId} This is useful for REST APIs that expect specific information in the URL. We would like the parameter options to include custom fields as well.

KerryMcD · ‎10-06-2017

We have hundreds of Zuora users and it can be a real pain finding a user on the user list, especially if their first and last names are in the middle of the alphabet. Would love the ability to: Search for a user by name Sort the list by other columns like role Filter the list (build list views like in Salesforce) so I could easily pull up a list of all Active users or all FinOps users for example. Be able to export any of the results of the above (so export only active users for example). This is a huge pain point for me as an admin. Thanks in advance!

bolaurent · ‎05-25-2017

I have credentials associated with Zuora: Community Connect Support Subscribed University This is kind of a pain; how about a unified auth system?

bolaurent · ‎09-23-2016

I typically have multiple tabs open to the UI. All the tabs have the same, not helpful, name. I really want these tabs to be named with the record that is displayed (a product, an account, an invoice, etc).

S_Mizu · ‎02-03-2016

The custom fields are currently displayed in the order in which the custom field was created. If I want to add a new custom field that is related to existing custom field, I would like to position it around the related custom field, but the new custom field is displayed at the bottom of the custom fields. I would like to control the display order of each custom field.

jasong · ‎09-21-2017

Support confirmed with me that when a tenant is configured to use SSO and a user clicks the "logout" button, then it redirects users to the organization's SSO login page. However, session timeouts go to the ZUORA login page. This, in my opinion, is the wrong behavior. When a tenant is configured to use SSO, session timeouts should ALSO redirect users to the SSO page - that way if the SSO configuration still has an active token, the user can be redirected seamlessly back to zuora. Please upvote this. The lack of this feature is causing pains within my organization. :) Thanks.

bolaurent · ‎03-03-2017

It's a significant source of friction that I can't search for an object until I click on that object name in the sidebar, then the search window on the right. Please give us a unified search field, displayed on all UI pages in the same location, that searches all objects. So, for instance, if I enter "INV0000123" it gets me to an invoice, and if I enter "Foobar" it displays accounts and subscriptions named foobar*. Also, if there is only a single hit (as for instance, "INV000123" would produce), then take me directly to the record.

alexboster · ‎05-11-2017

We have a critical custom field (that represents the customer's unique database id in our systems) that should be unique. It would be very helpful if we could set the custom field in Zuora to be unique, such that Zuora would not allow us to create multple objects (in this case, Accounts) with the same custom field value. Our use case: When the customer converts (enters payment information), we send that to Zuora directly from their browser via the REST API. Our system then receives a New Subscription callout notification if the conversion succeeds. This is probably very standard. Then potential issue is that browsers cannot be considered 100% reliable. So it's possible we could send the Create Account REST call multiple times, even with various mitigations in our Javascript code. We can detect that this has already happened (indeed, every callout notification after the first would generate an error in our system that could be escalated). But it would be better if Zuora would just reject the redundant records.

brianh · ‎12-22-2017

There are API interfaces to manage most of Zuora except the users (not customers) of the organization. We would love to have our management systems and scripts to be able to update or change the status/role/etc of our users via an API. Part of this stems from the fact that user searching/sorting/editing in the web gui is painful when finding and editing users (no filtering/searching, limited results on one page forces multiple Next, Next, Next, when the users name is in the middle of the alphabet, etc).

Happy Business Starts Here

Vision

Products

Zuora Central Platform

Products

Connect Marketplace

Solutions

By Industry

By Role

Customers

Resources

Resources

Subscribed

Support

About

Admin & Settings Ideas

Reset All Passwords Next To Add User Button - Insa...

Support new REST API in Production Copy (Services)...

API Idea: Please support OAUTH

Allow for programmatic update of API settings

Separate Contact edit permission from 'Modify Account'

Salesforce "Zuora Connection Setting" programtically

Allow setting the API URL/username/password via NamespaceUtil APEX class

Show the currently running release version in the admin setup person

User account modification date

Ability to include old and new values on a given field in callout (via Notification Framework)

Require Audit Trail

Get email notification history by Customer Account or Billing Batch

Export / Import configuration

Allow Notification Definition to be created for multiple or ALL Communication Profiles

Allow parameters in Callout Notification Base URLs

Search for a User and/or better sorting of user list

Too many credentials!

Give UI tabs useful names

Display Order of Custom Fields

Session timeouts should redirect to the SSO login page

unified search in Zuora UI

Ability to make a custom field unique

Setup API to allow user management