Best practices in a multi-tenant environment (startup/ISV)

[Benjiiim]

As a startup/ISV publishing an app in the Store, it is good to simulate a multi-tenant environnement as soon as possible in the dev process.

I would like to use Teams Toolkit to create such an environnement, with a clear separation between resources that are managed on the ISV side and resources that are managed on the customer/user side.
For example:

• Azure resources such as Bot Service or Web App should be provisioned in the ISV Azure subscription (which is using the ISV Entra ID as the directory)
• App Registration should be done in the ISV Entra ID tenant (the service principal will be created later during first app consent in the customer Entra ID tenant)
• Teams app in the Dev Portal should be register with a ISV Entra ID account (and not with a customer Entra ID account)
• Microsoft 365 tenant should be under the Customer Entra ID (ISV doesn't have to have M365/Teams/Copilot licenses to manage the app)

I've configured Teams Toolkit with two accounts:

• Azure account: one user account in the ISV tenant
• M365 account: one user account in the customer tenant

The first issue I'm having right now is the fact that the App Registration is created in aadApp/create (and updated in aadApp/update) in the tenant of the Microsoft 365 Account of Teams Toolkit (which represents the customer).
How can I tell Teams Toolkit to use the tenant of the Azure Account of Teams Toolkit instead (which represents the ISV)?

The second issue I think I will have is the fact that the Teams app is created in teamsApp/create (and other teamsApp/* steps) with the Microsoft 365 Account in Teams Toolkit.
It would be better if it can be created with the Azure Account instead.
However, I'm not sure that would allow the app to be deployed to another tenant so an extra step might be needed to deploy the app in the customer tenant by sideloading it for the user or for the entire org.

I've tried to configure Teams Toolkit this way:

• Azure account: one user account in the ISV tenant
• M365 account: same user account in the ISV tenant

The pro is that all resources are deployed in the ISV tenant with this config but I then need to manually deploy the Teams app to the customer tenant (I can't use teamsApp/publishAppPackage for that as it will try to use the ISV tenant account). Furthermore Teams Toolkit UX is not happy because the account used as the M365 account doesn't have Custom App Upload rights.

Edit : the more I think about it, the more I think that having 3 accounts configured with Teams Toolkit would help:

• An optional publisher account, which would be used for the Teams app registration/update in Teams Developer Portal and for the Entra App registration/update actions.
• The Azure account, which would be used for the Azure resources deployment actions
• The M365 account, which would be used for publishing the Teams app package to the M365 tenant (teamsApp/publishAppPackage action).

Any thoughts?

[therealjohn]

@Benjiiim

The first issue I'm having right now is the fact that the App Registration is created in aadApp/create (and updated in aadApp/update) in the tenant of the Microsoft 365 Account of Teams Toolkit (which represents the customer).
How can I tell Teams Toolkit to use the tenant of the Azure Account of Teams Toolkit instead (which represents the ISV)?

You can't. Instead, you could manually create this Entra App. To make the toolchain happy, you can just provide the Client ID for that in the env variables that would have otherwise been filled by aadApp/create. You could then safely remove that action from the YML to avoid issues later.

The second issue I think I will have is the fact that the Teams app is created in teamsApp/create (and other teamsApp/* steps) with the Microsoft 365 Account in Teams Toolkit.
It would be better if it can be created with the Azure Account instead.
However, I'm not sure that would allow the app to be deployed to another tenant so an extra step might be needed to deploy the app in the customer tenant by sideloading it for the user or for the entire org.

The teamsApp steps are not Azure resources, this is why it doesn't use the Azure account - but I see why you want to do that.

Any thoughts?

Yes, sorry for the confusion on all this and thanks for taking the time to start the discussion. What you're wanting to do is valid and unfortunately the opinions in the toolkit aren't letting you work like that.

What I'd like to propose is that the accounts used by the toolkit are configurable per environment instead of global to all environments. So instead of:

m365 account
azure account
├─ local
├─ dev
├─ {env name}

We could do something like:

local
├─ m365 account
├─ azure account
dev
├─ m365 account
├─ azure account
{env name}
├─ m365 account
├─ azure account

However, this doesn't solve for some of our actions not letting you specify between which account to use, like aadApp/create. I think we could shift to using the Azure account for this since it's an Azure item - but it means you need an Azure account to get started with bot development which we've tried to avoid.

What else are we missing with that proposal for your scenarios? If you'd prefer to chat on a call, let me know how to contact you and I'll set it up.

[Benjiiim]

Thanks a lot for your time and to make this discussion possible John,

I definitely understand that you had to make some choices to make the tooling powerful while being simple enough to make possible most of the scenarios out there.
I'm trying to find the right balance between adapting my requirements (which might means lowering my expectation) and hoping some improvements on your end to implement my scenario. :-)

The teamsApp steps are not Azure resources, this is why it doesn't use the Azure account - but I see why you want to do that.

Well, the aadApp steps are not M365 resources so that's strange to use the M365 account for that - but I see why you do that. ;-)

Being able to choose (or override) which account to use step per step in the teamsapp.xxx.yml file would be great. On top of that, being able to configure more than 2 accounts if needed would be awesome.

Regarding your proposal, configuring the accounts per environment would be appreciated, as it would simplify the switch between envs, without the signout/signin process. That would be nice but not a game changer.

However, if you add the ability to define a teamsapp.env.yml file per env (cf our discussion on #12550), that might open the realm of possibilities...

Thanks again

[Benjiiim]

To add to the discussion, I just had a new requirement that made me create a new App Registration through Teams Toolkit (an app registration used for a service to service client credential OAuth flow I need to use in my Teams bot backend).
In the dev environnement (not local), adding a new aadApp/create and a new aadApp/update is working like a charm.
However, in the prod environment, where the new app registration should be done in an other Entra tenant for some reasons, Teams Toolkit can't work.
A partial workaround would be to create the app registration manually and to provide the clientId in the corresponding env files for aadApp/create to ignore the step. However, the aadApp/update will fail as it won't find the App Registration to update through the Microsoft account used by Teams Toolkit.