We recently submitted our Add-in for approval to be available on AppSource/Office Store and failed approval. Some of the feedback and policies make sense and we have addressed those items. However, there are a few policies that I'm not sure how to address and looking for guidance.
Policy 7.1 & 7.16 are about the supportURL not being publicly available and requiring Sign-in. Our add-in is not a general user add-in but targeted to Enterprise Customers of our Platform. They are provided a login for our support site so is this not sufficient? Do we really need a public url for an add-in targeted to Enterprise Customers?
As I was writing this I found the following link and wanted to make sure this was still valid and the same guidance for my scenario: App Submission - Help/Support Link Requirement
Policy 11.3 are about the Start-up experience needs to engage the user and show value proposition. Our users are Enterprise Users and have signed up for platform in which we will already guide them to use the Excel Add-in. Since they already know the value proposition from our sales team is there a way that this can be handled in our scenario without needing an explicit startup video or wizard walk through of app features?
Yes, this must be a public URL. The support link in your Seller Dashboard listing appears on the AppSource website so must be publicly available. It can be a link to your main website / or a contact page on your main website.
Have you seen the documentation on submitting Enterprise add-ins? This outlines which policies are not applicable when submitting an add-in which targets larger organizations and enterprises. It also explains how to declare, via test notes, that you are submitting an Enterprise add-in.
Related
We have a web application that occasionally receives web request that we detect as attempts to inject SQL code, from Google virtual servers (Compute Engine).
I was asked to find a way to identify who is responsible for said machines, so that we can take the corresponding legal actions on our part, or at least, confirm that Google shut down those servers.
What I need is to find a way to communicate with Google, by email or chat, but I haven't found information about it.
EDIT 1:
I have tried to communicate with Google to indicate the information I am looking for, but the only contact available in my case is with the billing department, which could not confirm that they will give me that information if I buy a technical assistance package. On the other hand, I understand that this package is to review requirements of the applications that you own, but in my case I am looking for legal information.
What was recommended to me was to enter the corresponding application in
https://support.google.com/code/contact/cloud_platform_report?hl=en
but I have not received a response for weeks.
I am disappointed in Google, especially because of the importance of computer security.
I will keep searching information.
You can find all information concerning Tech support, phone support and Chat support in your Google Cloud console. Also, this doc shows different supports based on your support role or package.
I have a question regarding permissions on PowerApps. I know external users from the current tenant are not able to use any PowerApps app. Here the official documentation and here from PowerApps Q&A.
But, is there a way to have trusted accounts or accounts from trusted domains and grant access to PowerApps apps? If not, is it in the current PowerApps roadmap and the roll out date for it?
Very good research, and those are great links.
Yes, currently PowerApps is limited to single Organization (tenant), nothing can be done to open it up/share across any other trusted tenants.
PowerApps portals is the one you are looking for, which can be established to external domain users (B2C & B2B).
PowerApps portals in private preview now, it will be available for Public preview from Jul '19 maybe. This was announced on Microsoft Business Applications Summit on June 10th 2019.
Introducing PowerApps Portals: powerful low-code websites for external users
We are developing a Word Web Add-In that will be used exclusively by our customers rather than the general public. Customers will need to log into the Add-In in order to use it with credentials we supply. My question is, is this Add-In ok to be distributed via the Office Store? Will it fall foul of the validation process if its functionality is not publicly available ? Obviously, we can supply credentials to the verification team at Microsoft in order to get the app published.
If this is a problem, how do ISVs distribute Web Add-Ins to customers external to their organisation (i.e. Without Sharepoint or Office Admin Centre)?
This model is supported via the Office Store - this blog post on add-ins which target organizations and enterprises rather than consumers may be of interest to you.
Please ensure that your add-in description clearly states the need for an additional account, as well as supplying test credentials for the validation team to use.
I'm confused by the preliminary documentation on the OneNote dev blog. Does it mean that a Native App accessing has to use (compile in) a Client ID specific to an individual O365 subscription?
The implication being that an Commercial App would need recompiling for each different O365 customer. Is this the intention?
If so then this severely limits the utility of OneNote Api in O365.
I'm hoping that I've misunderstood, can anyone advise please?
Paul,
Apologies if we confused you with our initial preliminary docs. Definitely not the case. The app ID is relative to the O365 tenant that publishes the app, but you just flip over the switch to say it is a multi-tenant app for it to be able to be consumed by any tenant.
I currently have a developer account setup in box and looking for steps to move it to production. I cannot find details on
If there is number of users allowed
How to turn production mode on
I am have setup initial account with auth redirect url. Configured my app key and token in my web application.
In terms of "productizing" I've heard a few different ways this term
1) To just make an app generally useable among consumers of the third party app, all that is needed is a functional integration with Box APIs. Assuming that you have implemented oAuth correctly and integrated our APIs functionally, there is no barrier to everyday users to using that integration between Box + third party app.
2) To make an app available to Box users ("productionalize" is a term I hear often), the best way to do this is through our gallery. Developers can follow these instructions for creating a listing in our App Gallery: cloud.box.com/appgallerylisting