New command: `viva engage community add`

[milanholemans]

Usage

m365 viva engage community add [options]

Description

Creates a new community in Viva Engage

Options

Option	Description
--displayName <displayName>	The name of the community. The maximum length is 255 characters.
--description <description>	The description of the community. The maximum length is 1024 characters.
--privacy <privacy>	Defines the privacy level of the community. The possible values are: public, and private.
--adminEntraIds [ownerEntraIds]	Comma-separated list of Microsoft Entra IDs, assigning admin privileges to the designated individuals. Required when using application permissions. Specify either adminEntraIds or adminEntraUserNames, but not both.
--adminEntraUserNames [adminEntraUserNames]	Comma-separated list of Microsoft Entra UPNs, assigning admin privileges to the designated individuals. Required when using application permissions. Specify either adminEntraIds or adminEntraUserNames, but not both.
--wait	Wait for the operation to finish.

Examples

Create a public community and wait for the community to be created

m365 viva engage community add --displayName "Software engineers" --description "A community for all software engineers" --privacy public --wait

Create a private community

m365 viva engage community add --displayName "Software engineers" --description "A community for all software engineers" --privacy private

Default properties

No response

Additional Info

API

https://learn.microsoft.com/en-us/graph/api/employeeexperience-post-communities?view=graph-rest-beta&tabs=http

The API returns a URL which you can poll to check the status of the community. I suggest that without the --wait flag we just return nothing. When --wait is specified, we return the community object on completion.

Without --wait:

https://graph.microsoft.com/beta/employeeExperience/engagementAsyncOperations('3a6fdce1-c261-48bc-89de-1cfef658c0d5')

With --wait:

{
    "id": "eyJfdHlwZSI6Ikdyb3VwIiwiaWQiOiI0Mjg1NzkwNjE3NyJ9",
    "displayName": "Financial Advice for Software Engineers",
    "description": "A community where financial advisors who represent customers from software engineering profession can discuss advice and suggestions for their clients.",
    "privacy": "public",
    "groupId": "36c434cc-7d12-4280-9849-08da93548c7c"
}

Remarks to be included in docs

• Warning that API is in beta and is subject to change
• It is limited to networks in Native mode only – legacy and external Yammer networks will not be able to use this API for community creation.
• Creating a community will create a linked Microsoft 365 unified group as well.

[waldekmastykarz]

I suggest that without wait we print the polling URL to console, just like we do for the external connection schema add command, in case folks want to poll manually.

For privacy, could we consider a reasonable default or should user always explicitly specify if they want a public or private community?

[milanholemans]

I suggest that without wait we print the polling URL to console, just like we do for the external connection schema add command, in case folks want to poll manually.

Ok, updated the specs.

For privacy, could we consider a reasonable default or should user always explicitly specify if they want a public or private community?

The API has no default value, you must provide one. I don't know which of the values we could consider default.

[milanholemans]

The challenge for this (and the get) command is that we currently have yammer group commands which are not compatible with these new graph community commands. In my opinion, we should move all yammer group commands to viva engage community, and somehow try to make them compatible with each other however few commands use graph API and others use the yammer API.

[waldekmastykarz]

I haven't compared the Yammer and Graph APIs so can't tell with certainty, but my gut feeling tells me that the data returned will be incompatible and we won't be able to move from Yammer to Graph APIs without introducing breaking changes.

[milanholemans]

I haven't compared the Yammer and Graph APIs so can't tell with certainty, but my gut feeling tells me that the data returned will be incompatible and we won't be able to move from Yammer to Graph APIs without introducing breaking changes.

Yes indeed, as discussed before, we'll just leave the group commands untouched and just introduce 2 new community commands.

[Adam-it]

Yes indeed, as discussed before, we'll just leave the group commands untouched and just introduce 2 new community commands.

Thats a bit of a bummer but in the end I agree this is the best we may do for now to keep moving forward and we should consider 'refactoring' the existing yammer group to Graph API for v8 (till end of year). We should create a separate issue for that. other than that LGTM and lets open this one up 👍

[waldekmastykarz]

Thats a bit of a bummer but in the end I agree this is the best we may do for now to keep moving forward and we should consider 'refactoring' the existing yammer group to Graph API for v8 (till end of year).

Not necessarily. We have other areas where we've got similar commands on Graph and SPO. As long as there's no parity, I think it's good to offer options as long as it's clear when to use which one.

[Saurabh7019]

Can I work on it?

[milanholemans]

Sure @Saurabh7019, thanks!