No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

No. ApplicationID isn't know until after the resource is finished being created, but you're requiring it in order to create it. This cannot work.

<@U012UJTT55M> would it be possible to create the resource and then modify its configuration in the same file?

No. Pulumi is declarative. Creating and editing aren't Pulumi concepts. Only "making a cloud resource be the same as this code resource".

Wouldn't something like `${baseUrl}/name` be better, and more human-usable?

<@U012UJTT55M> existing architecture issue

I think you'll have to do this in non-Pulumi code. Or els change your standards.

Even doing this through the console is a two-step process. Tell your team / architects that this is an anti-pattern than will cause issues later. And there's simply no need for it.

I mean two step in then sense its multiple commands, but it is doable in one script which is nice.

Why would this url cause issues?

Because the URI can't be created until after Azure has created the application. The ApplicationID can't be known in advance, so you can't set the value at creation time. You have to wait until creation has completed.

If you destroy and recreate the application (which you might want to do at any time, and you will have to do at very awkward times like during disaster recovery), then you _will_ have to update the URI, which means you _will_ have to update anything that knows about that URI.

Having a fixed URI for a logical application, instead of a variable URI for a specific application, is a far more robust option.

<@U012UJTT55M> I see... Thank you for your help, I'll reach out to my team about it

image.png

<@U012UJTT55M> I've discussed it with my team. It seems that the configuration of the url with the variable id in it comes from this <https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/tab-sso-manifest|MS doc page> (I have attached an image of the code I'm referring to on that page) - we are using the Azure Bot Service in our architecture. I have been testing without the usage of the bot-id in the url and I haven't found problems yet, but I was wondering if you might know more about this design choice from Microsoft. Note that the bot-id is identical to the app-id and is set by the application registration.

Nope, sorry. Is there an explanation for why they use the ID? Maybe that's just the natural human inclination to overspecify with insufficient constraints? With just that picture, it's impossible to know if that config is "better" than, for example, `api://{Subdomain}.<http://example.com/{Azure|example.com/{Azure> AD AppName}`.

My guess is that that URI is overspecified, and it would have been better to put simply `api://{hostname}.{domain}/{pathToApp}` or even just `{appUri}`.

No unfortunately there is no explanation for their choice :confused:

But those hunches and ideas seem reasonable