About lukasz

lukasz · ‎08-29-2018

lukasz · ‎08-29-2018

@rclous, we're currently working on exposing all Zuora settings via API, and being able to change custom field definitions is on the list. We're targeting to have this released to our customers this year.

lukasz · ‎07-31-2018

@kcavanaugh, thanks for checking in. We're starting to plan this out, by starting with some Engineering research starting next month. I still don't have a concrete timeilne, as we need to get this research done. The main wrinkle we're working on is making sure that we capture 100% of the changes in the system, without dropping anything. This is because we expect the Audit Trail to be the authoritative source of this information, and dropped information would not be tolerated. Would love to get folks to come back and tell me that's not required...

lukasz · ‎06-15-2018

Agreed that this is a good idea. As we re-design user login, we will look to add this in.

lukasz · ‎05-14-2018

Thank you, @rjohnson, will put a note out when we're ready for you to take a test drive of these API's.

lukasz · ‎05-07-2018

@msonsma, we're still in internal testing and release cycle, so no public documentation is available right now. However, I'll say that this is simply a get/set API, that allows those operations either on one, a set, or all settings. Conflicts will be returned as errors. This API will not perform a diff, but you should be able to take two exports and diff them externally, that was one of the design goals. The plan is to include custom fields, I still need to look into custom reports, but I feel like that's in our scope, so it would make sense to include them.

lukasz · ‎04-30-2018

@giancarlofenu, thanks for asking. We're going to be rolling out the first release of this, currently internal, in May. Assuming that goes well, we'll follow up with a public release. Is there anything you're working on where this feature could help?

lukasz · ‎04-18-2018

@nataliemcguire, I see what you mean. We're actually moving over to Orders, which will change the Amendment behavior. For general effort around which fields are required or not, that's a bigger effort and not currently we're planning on tackling any time soon.

lukasz · ‎04-18-2018

@Hajime, I think you're asking for something quite different and likely something we can already do, by customizing the "Send to Zuora" button in SFDC. Could you post your question on the Zuora CPQ Discussions board instead?

lukasz · ‎03-01-2018

Folks, we're currently working on providing an API to manage users and roles, but this will likely be released later this year. At this time, there's no way to automatically create users thru the UI (via flat file) or API.

lukasz · ‎02-28-2018

lukasz · ‎02-28-2018

Hi @Jean-Yves, we're planning to take a look at the different authentication schemes for callouts at some point in the future. We'll look into this at that time. I'm assuming this is not blocking you from using Zuora callouts, it's just another authorization/security option?

lukasz · ‎02-16-2018

Just a quick update here, we're done with the design of a revamp of User Roles & Permissions. It includes the concept of a true Read Only role. We're currently working on staffing this within this calendar year. Nothing set in stone, but we're getting closer!

lukasz · ‎02-16-2018

Hi @suchitraramani, please use the API Sandbox URL instead of Production: curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=XXX" --data-urlencode "client_secret=XXX" -d "grant_type=client_credentials" " https://rest.apisandbox.zuora.com/oauth/token "

lukasz · ‎02-16-2018

Got it, yes, sounds like you'll be migrating over everything to your existing tenant. Although it should be relatively straightforward to import customers and the current state of their subscriptions, you'll want to take special care with any future dated amendments, and with setting trigger dates, so that no customer is billed twice (once from the old tenant, and again from the new one). Lastly, Payment Method information, like Credit Cards, need extra special care, but, again, we can help you here with PCI-compliant transfer between the tenants. When you're ready, please reach out to our support team to schedule a consultation with our services team, either to help you with the Payment Method transfer, or the entire task of migration.

lukasz · ‎02-15-2018

@rjohnson, will the subsidiary continue to be administered separate? I.e. run it's own billing runs, accounting period close, and have it's own admin staff? Or do you plan to administer it together with the main business? The reason I ask is because if it's the former, you may want to consider Multi-Entity as an option. It does provide some nice benefits around separation of operations, while still allowing a single-sign-on experience and sharing of accounting periods as well as select products for cross-sell purposes. In either case, you'd be migrating over data from the subsidiary into either your current Zuora tenant or the new entity created under Multi-Entity.

lukasz · ‎01-30-2018

@kcavanaugh, yes, an update is long overdue. Unfortunately, we haven't started on this yet, due to other roadmap priorities, however, this is now received enough votes to be our top candidate for what we start to work on next. I'll try and provide another update in a couple of months.

lukasz · ‎01-16-2018

This is currently not possible. However, we're rolling out a new feature called Event Framework & Notifications that will include API's to access the e-mail template. You should see this announced in the next couple of weeks.

lukasz · ‎01-16-2018

Makes sense. I'll look into it as we re-vamp the user management area. Thank you for logging this request!

lukasz · ‎01-14-2018

@BobbySingh, we're not planning to touch SSO until later this year, say Q2 or Q3. I'll provide update around then if we're able to get this in.

lukasz · ‎12-20-2017

Ah, I see what you mean now. So, no, today, we don't have another format for the results from AQuA to be provided other than either CSV or Zip CSV. I believe we chose this format because it was ultimately meant for large extracts, and the idea that all responses would be consistent. Obviously, we have provisions for supporting other formats. I'll let the community here upvote the request. Thank you for getting back to me with the details of the issue.

lukasz · ‎12-20-2017

@vkannan, did you mean 2GB? Please note this article in our KC, which addresses what to do if the response files are bigger than that.

lukasz · ‎12-18-2017

Welcome, @pkells! Sorry about the lack of updates, but we're really close to publishing our new notification framework out. We want to do that first, and then this item is in our backlog to handle right afterwards. Thank you for chiming in, and hopefully voting for this issue as well!

lukasz · ‎10-18-2017

This is a fair note. Please note that we are slowly transitioning to truly REST-ful API's, and in the interim, we've chosen to provide 100% REST coverage of our API's, with the downside of some of the API's not being truly REST-ful. Specifically, when you are working with any endpoints that begin with /v1/action or /v1/object, you'll get the same response as we provided with SOAP. All other endpoints should be REST-ful. Bear with us as we re-design all of our API's over time.

lukasz · ‎09-21-2017

Hi @Emmanuel, thanks for posting this. We've actually been looking into this and found that it's a trade-off between complexity and effort. Meaning, very few of the responses we get back are non-retriable, and for that shouldn't, it doesn't harm anything if we do retry. Could you provide examples where retrying would cause issues?

lukasz · ‎09-20-2017

@jkwas, well, this is very timely post by you. We're actually currently discussing the pros and cons of the product-role approach we have now versus a more traditional user role approach. One of the concerns with switching to the user role approach, is that any small tweaks would require a new role. Over time, it might be hard to know which role is the right one to pick. On the other hand, I do see the ease of maintenance and assignment of roles to new users. Any comments?

lukasz · ‎09-19-2017

Hi @chrisorme, we just rolled out OAuth for API connections in August, which would allow you to not worry about expiration dates for API clients (previously we prevented expiration of API only users as well). Does that address what you're looking for, or is there still a use case where (outside of the API users) your different users need a different password expiration timeline? And if so, what would your requirement be for those timelines, say for Admin vs. Standard users? Would addition of 2FA for certain users, like Admin, relax that requirement?

lukasz · ‎09-18-2017

@tonglongjeff, this is still top of our backlog. We haven't started in it yet, however. Our current big focus is an initiative called Universal Sandbox, which will address the growing Production Copy Environment limitations.

lukasz · ‎09-12-2017

@BobbySingh, we're in the process of looking at our authentication and SSO implementations, but it may take a bit of time to get to this still. Please don't forget the vote for this feature, if it is important to you, right now this only has 1 vote...

lukasz · ‎08-30-2017

@cthilgen, this is interesting. When you say "paved over by a refresh from one of our sandboxes", are you referring to our PCE environments (i.e. Services)? Because if so, then all users and permitions already get copied over in that process. I don't know of any other "refresh" that we provide at this time, can you confirm or elaborate?

Happy Business Starts Here