This would be a huge help for us as well as we often have notes that exceed the 255 character limit. As @Renaldo mentioned, these need not be indexed fields, but would be things referenced on an individual account basis or potentially used on an invoice merge template (i.e. custom terms or other notes to the customer)
I'd love to hear what the use cases are for 2k or 4k fields. At some point, these are starting to be used as a data store, could the new Attachment feature be used for this instead? Please note that we're also looking into adding a concept of Notes that, similar to Attachemnts, could be entered on select Zuora objects (likely Account, Subscription, and Invoice).
For us there are three primary use cases that have come up:
1. Notes
This could be anything from notes on collection efforts for an invoice, or general notes on a customer's billing account over its lifespan. The full context of these notes would be dependant on their ability to be sync'd to Salesforce since ultimately we want any customer centric notes to be surfaced there. But when our billing / collections team is working in Zuora, it would be nice not to have to jump back and forth.
If Notes are being concidered as a first class feature thats even better as then they can be timestamped and marked with the person that made them and properly sorted. Without this you get odd conventions that have to be created when multiple users make notes (i.e. JF - 20160612 - My note here) and you ultimately will still run into limits if there is a large enough history.
So in short consider this my vote for proper notes on objects ;-)
2. Larger custom text to be merged onto invoices.
Sometimes more detail is necessary for an invoice such as custom terms or in special circumstances we have product descriptions that are getting longer as customers have requested that it describe all the functionality included with that SKU. While most of these would not be anywhere near 2 or 4k characters they tend to exceed 255 which is just not quite big enough...
3. Product Catalog Metadata
In our case our products are defined by a set of key/value pairs that our provisioning system uses to build the plan that they are on. It would be nice for our provisioning system to read these attributes from the catalog master (Zuora) rather than having to maintain its own copy. Now this may, of course, change slightly as the catalog master moves to Salesforce with the introduction of bundled products in Quotes.
In the case of DAZN, as Zuora is building a custom integration to process Apple, Google, Amazon (and more) IAP recurring subscriptions, fields of such lenght are absolutely vital for the completion of these projects, as the receipts returned by these platforms exceed by defauly the max lenght currently allowed by zuora's fields.
Receipt ID returned by Apple, for example, can currently NOT be stored in any of the existing fields and this causes us additional development overhead as well as complications for what could otherwise be a pretty straightforward implementation.
Please include a good UI design for large text fields. In the current UI design, a custom field holding 255 characters is cramped/packed in UI field that nearly can display the first 30.
Our use case for this is our credit control team add notes to the invoice object to track what credit controlling they've done. This field is then used on reports showing outstanding invoices (using the Invoice object).
The current field size (both in terms of characters but also in terms of width on screen when entering notes) means this is difficult to use.
I'd ideally like more characters available and for the field to be multi-line when editing.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
