S3 - Default ON for each Tenant?

Related products: None
Is there a business or technical reason we default S3 off for each new tenant created?


We don't charge more, no licensing, etc. and push customers to increase adoption of S3...is there a reason we wouldn't make it easier on the creation of each tenant and default it on?





Thanks!
We may not charge extra but it does cost us extra. When you flip that switch in Tenant management to on that is when the S3 bucket is actually created for that customer. This is also the point at which AWS starts charging us, it's what we like to call "just in time provisioning". There is no point in paying for an S3 bucket for a customer who is not currently or is not planning on using the S3 connector. 
Can we give this on/off switch to the customer? Is there any example where we have said no and not turned on for a customer?





Feels like a very unnecessary step that prevents customers from being in control and takes time from our Gainsight teams.
I'd like to second this, but understand Marcus's note.





For some Training (all of the Admin track - 100, 200, etc.) we will require S3 so we can teach to it with hands-on exercises.  





Would be nice to have a streamlined way to activate this - right now I understand the process is to email support or create a ticket with the SFDC org IDs.  When we do more live training (soon) it'll be an obstacle.
I can see the logic in that; Although I think there would still be a concern around giving this option directly to the customer . The specific case that comes to mind would be a customer enabling the S3 feature and provisioning a bucket but then changing their mind and never using it. Thus we could end up in a position where we are paying extra for S3 buckets that our customers are not using.  





How are we handling these requests in on boarding now? It does not take that long to turn on the S3 feature, just a few seconds. Anyone with access to Tenant management can do it, I think so long as we record/capture that this was done we should be good. 
Marcus - Thanks for your feedback.





If you can share an example of where we have not turned on an S3 bucket for any customer that asked, or where we benefited from making this harder for a customer than a simple on/off - then it makes sense to keep the control and slow down the process for a tool we include in our licensing.





Otherwise, I still feel this is an unnecessary series of steps for onboarding, support and customers who want to use our S3 tool and we can improve on the experience.





Thanks,
Devin - I appreciate your thoughts on this and wanting to improve the end user experience.





I am not currently aware of any such situation in which we have denied a customer access to our S3 tool, that does not mean that this situation has never occurred just that I am not aware of it. Aside from the fiscal issues at hand I have a serious security concern as what you are asking for would essentially give a customer governance over the provisioning of settings on a production server. That level of access aside we still need some sort of record in place that tracks who has had this turned on and who has not. 





I think this is a conversation we should have Ashok involved in as I know he has many changes planed for the S3 connector and something similar to this may be on the road map currently. Ashok would really be the best resource to consult on this but I would not recommend this as an option unless we had some infra changes on the backend first. 
Terms & ConditionsCookie settings