Provide a mechanism for deploying an add-in to a group of users and specify property bag of settings to apply to the group
We already have a way of deploying add-ins to group of users within a tenant, but it would streamline a lot of scenarios if during that deployment for an add-in to a group that a "property bag" of settings/configuration could also be specified. This would then be available via the Office.js API.
Here's one very realistic use case scenario:
Commercial third party add-ins would require some form of subscription/licensing engine, consider a subscription that an organization would buy simplifies down to a subscription id. The question is really then around how do we bind users to this subscription id?
Here's some ideas to give you an idea of our thinking:
* Obviously we could build into the UI of the add-in a place for every user to enter the subscription id (as save this to the add-in settings), but this is not a very nice experience for an enterprise.
We could use the domain of the users email address as the unique key to lookup if a subscription exists for that domain (this falls down when you have multiple subscriptions within an enterprise – different user groups on different plans or different billing for different areas of a large enterprise).
Similar to above we could also use the Office 365 tenant id but again this doesn’t cater for different groups of users in the same organisation.
We could provide a subscription administration portal and make the administrator identify all users of the subscription (lookup AAD) – very labour intensive for the poor admins
What we think would be useful for this is for the add-in deployment model to provide a mechanism for deploying an add-in to a group of users (we have this already) but also to specify a “property bag” that applies to that add-in when it is deployed to that group of users. This would provide the ability to deploy the add-in and specify the subscription id to use at the same time.
Outside the scope of subscription/licensing this mechanism would allow add-in developers a way for different organisations to apply enterprise wide add-in settings during deployment.