heroku / roadmap

This is the public roadmap for Salesforce Heroku services.
189 stars 11 forks source link

New "Payer" role for Heroku Online Teams #53

Open kouroubel opened 1 year ago

kouroubel commented 1 year ago

Required Terms

What service(s) is this request for?

Heroku Teams

Tell us about what you're trying to solve. What challenges are you facing?

What is missing from the Heroku Teams is a "Customer" role that has access to the credit card information and invoices but cannot remove other team members or transfer the application. Customers would like to (and should) be independent from the developer w.r.t the billing of an app, so if something happens to the developer they can still use the app.

Currently, the only way to do this is by creating a Team and give Admin privileges to the customer. However, as an Admin the customer may remove other team members (i.e., the developer) and hijack or even transfer the application to other Heroku accounts.

This would be a great feature to implement and one that is not offered by anyone else....

afawcett commented 1 year ago

Thanks @kouroubel for your thought here. What I am getting from your idea is you are independent contractor and you wish to enable your customers, who own the Heroku account, to managing billing but not gain access to what you have implemented for them. Is this concern due to the possibility of them breaking something or IP, both or other?

Also can help me understand a bit more about the business model and agreements here. It sounds like a Service Implementor model but also shades of an ISV model, where in the later case you publish your app as a package (thinking of the Salesforce AppExchange model here) - though in this case the app is more general and less bespoke.

kouroubel commented 1 year ago

Hello @afawcett. I am an independent contractor who develops web applications for different customers. Each customer has exclusive use of an application in my Heroku account. The charge is in the form of an annual subscription which comprises my fees and Heroku costs (paid by me every month).

Some customers have expressed the (rightful) concern that they will not be able to continue using the application if (for any reason) I do not pay the Heroku bill.

My concern of creating a team and giving the customer Admin privileges, apart from breaking something intentionally or unintentionally (security concern), is that they could shut me out of the app and stop paying the yearly subscription (financial concern). Even worse, someone (another developer) could clone the application, get access to the code and potentially use it as his/her own (so IP as well).

Regardless of how you look at it, a customer is a customer. Their single role and purpose in a Team is to take care of the monthly billing. I shouldn't have to give them Admin privileges just for that. It opens the door for things to go wrong...

afawcett commented 1 year ago

Thanks for your feedback @kouroubel. Our customers sharing their Heroku account to their customers is certainly a first I've got to say and as you say raises a lot of challenges. We do have other asks here about adding more fine grained security controls such as env vars. That said even with those this pattern seems quite fraught with compliance, governance and security challenges.

A thought. From what you've said I assume you don't want them breaking the app or its config, so assume the access they want is some kind of monitoring or other specific set of needs? If so, have you considered building a web experience around the Heroku API where you can control the experience and access? https://devcenter.heroku.com/articles/platform-api-reference

friism commented 1 year ago

@kouroubel I'm trying to distill out your requirements, can you check if the below seems right?

  1. You want a way for your customers to be billed for the Heroku resources consumed by the apps you built for them (which is currently working correctly thanks to how you're using Heroku teams - since the customer's credit card can be added to the team associated with that customer)
  2. You don't want customers to have any other app access because they might mess up the app or grab your IP
  3. Your customers want confidence that they'll have continuity in case your Heroku account becomes delinquent

I think this is an interesting use of Heroku Teams, and I think the idea of adding a "payer" team role is a good one, and one we've heard from other customers (although for slightly different reasons). I don't really think that materially addresses concern 3) above but let me know if I'm wrong. If "payer" team role is what you're looking for, would you be OK with me tweaking the issue title?

Ultimately I'd suggest resolving the ambiguities in your relationship with your customers contractually, rather than us trying to bake controls into Heroku. Eg. if it's the case that you own the app and IP, then you should own the Heroku app, pay for the hosting and then charge your customers for the subscription and the cost of Heroku. And separately come to an agreement about continuity for your customers in case you go out of business (them having limited Heroku access to just manage billing doesn't seem like an adequate remedy, eg. they can't update the app or have someone else take over updating it).

Or if it's the case that your customers own the app, you should run them in separate Heroku accounts owned by your customers with you added as collaborator. If you have concerns with ownership of IP for this scenario, that should be clarified in whatever contract you have with your customers.

kouroubel commented 1 year ago

@friism points 1, 2 and 3 are exactly right. Feel free to change the title to something that reflects "payer" team role...

andre5oto commented 3 weeks ago

We have not lost sight of this and plan to address this issue at the beginning of next year.