Thanks for the feedback!
Please give us the control to enable/disable specific email notifications on the product/api/subscription
Terribly frustrating that we can't control the experience!!!
16 votesunder review · 2 comments · API Management » API management experience · Flag idea as inappropriate… · Admin →
Agree, Our API Developers do not need many of the emails that are provided out-of-the-box.
This is terribly frustrating that there is no configuration to enable/disable any of the built-in email notification.
2 votes0 comments · Azure Monitor-Application Insights » Metrics & charting · Flag idea as inappropriate… · Admin →
Thanks for the valid suggestion. Your feedback is now open for the user community to upvote which allows us to effectively prioritize your request against our existing feature backlog and also gives us insight into the potential impact of implementing the suggested feature.
Thanks for your suggestion. Currently, we don’t have anything planned in changing our billing meter from hour to minute. But will leave this request open and will include this in future planning discussions for our roadmap.
Thank you for your suggestion.
Cosmos Team, This needs rethinking! Per hour billing is pretty poor for this kind of real-time scalable technology.
For Example, Using Azure Functions on a consumption plan doesn't bill to the hour, it bills to whats consumed. Why should Cosmos be different and bill for what is not consumed?!
Given that you have buried the notice in the pricing FAQ it also looks like you are being intentionally sneaky about this.
I agree with Sam, per minute billing should be in place at the very least.
Once again, when is development going to start on this? being able to automate the creation and teardown of back-end resources in relation to API events is a must!
When is this likely to go into preview? Thanks
When a user signs up I want to receive an event, such that I can create an accompanying resource/s in my back-end domain
When a user subscribes to a product I want to receive an event, such that I can create an accompanying resource/s in my back-end domain.
When a user cancels a subscription I want to receive an event, such that I can tear-down resources in my back-end domain.
How do I want to receive the event?
Easiest would be for me to receive HTTP webhooks from API-M, but I'd be okay with anything, A service bus queue, EventHub etc
Have plans to use queues behind the scenes which would add some durability
I initially thought the same, but came to the conclusion of "why not just throw an exception?"
EventGrid has a simple job and that is to keep trying to deliver the message to the subscriber until it is completed sucessfully.
EventGrid really doesn't care *why* your function failed, I assume it treats any non-200 response as a failure and will invoke retries until it completes successfully or the 24 hour retry period elapses.
My opinion but having to explicitly return a Type that defines the success is unnecessary in this particular binding, as the EventGridTrigger is abstracting you from the complications of returning success or failure state.
165 votesstarted · 15 comments · API Management » API management experience · Flag idea as inappropriate… · Admin →
+1 for "organisational subscriptions"
This is needed badly when trying to create B2B APIs.
Typically the "user" aka a developer, of an integration, is not the "owner" of that integration, the "owner" of that integration is the "customer" aka the business who consumes your API.
A "customer" has 1 or more "users" aka developers.
A "customer" has 1 or more set of subscriptions.
A "user" has access to one or more subscriptions that belong to the customer.
We were just about to go into production with API-M and then at the last hurdle we find we can't sync the Widgets & Nav and Custom Pages. This is crazy that it is not supported.
Whats the point in offering the sync features and then missing a bunch of them?!
Absolute madness and super not impressed! This needs fixing immediately.
I support this.
Being able to set defined 'amounts' when creating a subscription would be great.
A Developer might initially only pay for 10 requests a second, but then at some point in the future upgrade to 20, 30 or 40 requests a second.
Yes we could achieve this right now by having 5 different products, but this would mean the developer would have to reintegrate against the API with the new ocp-apim-subscription-key which is a bad experience for the developer.
Maybe the real answer here is to be able to migrate a subscription to a different products and preserve the ocp-apim-subscription-key?
Thank you for your feedback. We are currently in public preview of blob storage lifecycle management. The feature set offers a rich, rule-based policy engine which you can use to transition your data to the best access tier and to expire data at the end of its lifecycle. See our post on the Azure Blog to get started: https://azure.microsoft.com/en-us/blog/azure-blob-storage-lifecycle-management-public-preview/preview/.
For any further questions, or to discuss your specific scenario, send us an email at DLMFeedback@microsoft.com.
Just received this MS after chasing :
"We actually will have something published shortly that will enable this with Logic Apps (some final testing underway on this), while the full API/policy based version of it will be shipped in CY18 per the current plan."
Please allow us to define a TTL/expiry on a container that applies to all blobs in the container, not just individual blobs! Thank you.
P.s. where is the update from the Azure Storage Team on this?
Your last response has been over 7 months, and not the "at least once per quarter" as promised.
Why doesn't the Azure Storage Team expose a public road map like other Azure Teams?!?
Thank you for your suggestion.
At this time this feature is not on our road map. We will leave this marked as unplanned for now and will revisit this in upcoming cycles and will update here if this changes.
Thank you for your suggestion and votes.
Thank you for taking the time to vote for this item. We have this planned for 2019.
This is an issue with the calculator, so moving this to Azure Portal.
Thank you for your feedback. We will consider ways to implement this.