Overcome JSON column formatting limitation that it does not support Rich Text Multiline

Inspired by the visualization of Microsoft 365 roadmap, I want to achieve similar for collecting and communicating the architecture vision and refined roadmap of our ART (Agile Release Train). As the purpose is mainly about communicating, I decide to just leverage a SharePoint list for it, no need to administrate in a planning tool (eg Jira Align). In the information architecture I add a column per aspect of the architectural roadmap topics: title, description, theme, year of delivery. And for the roadmap refinement a column per year in which to enumerate the steps I foresee in that year. The steps collected in a bulleted list, thus the column must be of type Multiline / Rich Text.

However, this decision results in a visualization challenge. Standard, SharePoint truncates in ListView the value of multiline columns to 4; and the roadmap does not display in entirety. List View / JSON formatting is not helpful to resolve: 1) ColumnFormatting does not support Multiline / Rich Text, and I don’t want to reduce to plain text ("It is NOT recommended to use Rich text fields in your formats"); 2) RowFormatting requires to specify the formatting for full view, while I am satisfied with the standard formatting of all other columns.

As pragmatic resolution I decided to revert to old-skool approach of DOM formatting. In Modern SharePoint you cannot directly inject a custom style, but via Modern Script Editor this is easily possible: [[Code]].

A risk of this approach is that Microsoft might change the standard formatting of list views: you cannot rely on DOM of standard SharePoint controls as “an interface contract”. But I can accept that risk: in unlikely case that Microsoft would make “breaking change”, all what would happen is that our roadmap visualization reduces to showing the multiline columns again truncated.

How-to enable for mobile device the seamless consumption of embedded Microsoft Stream on SharePoint page

SharePoint Online Modern Sites/Pages are by-design prepared for mobile / on-the-go consumption. An use case is to embed a Stream video on a page - either on-demand or live event -, and the audience then has the freedom to consume on regular workplace, or via their own mobile device.

However, be aware that in the latter case for seamless Stream behavior it is required that the mobile browser is set to 'Allow All Cookies / Block No Cookies'. Without this, typical the mobile browser fails from within the authenticated SharePoint Online context, next implicit logon the user to the embedded Stream service. The SharePoint Online Product Group confirmed this: To enable in Edge on mobile device seamless MS Stream behavior when embedded on SharePoint Online [modern] page, then infra prerequisite is that mobile Edge is configured to ‘Not block cookies’. The subject is current missing from the requirements stated on Microsoft official Knowledge Base. The Engineering Team will add this to the documentation for further clarity in the future.

Tip: for customizing on Modern Site shared with B2B guests, use SPFx and not PowerApps

In Modern SharePoint, the citizen-developer way for page customization is through PowerApps (instead of the dreaded InfoPath approach). This works out fine..., unless your site is shared with external Azure AD B2B guests. A condition for PowerApps usage is namely that the logged-on user is licensed for a PowerApps Plan. For regular member accounts this license is typical provisioned on onboarding time. For guest accounts you cannot trust that each of them has a PowerApps license already themselves, and then access to use the PowerApps customization requires that a license is assigned in the inviting tenant. But probably you do not want to assign licenses in the inviting tenant to Azure AD B2B guests. After all, one of the charms of the Azure AD B2B model is that for each paid Azure AD license the organization is entitled to invite up to 5 guest accounts without additional costs.

The result for guests that do not have a PowerApps license themselves, is a broken user experience. Instead of a working custom control / form in the SharePoint page, the guest site visitors are confronted with a notification about need for PowerApps Plan license:

A minimal approach to at least avoid the broken UI experience would be to hide the PowerApps control for guest accounts. But also this is not possible: audience targeting on arbitrary webparts is not supported in Modern Pages, see Overview of audience targeting in modern SharePoint sites.

In a SPFx control you can utilize an alternative for audience check, by check on permission group, or check on account type (member or guest). A code example of this approach: Show and hide SPFx Webpart Content based on user permission.

However, when using SPFx for page customization then you’re not subject to additional licensing on top of SharePoint license. So it would not even be needed to hide the control in case logged-on user is a guest account....

Conclusion: if you plan to share a Modern SharePoint site with external guests, then better not use PowerApps for customizing a page that is accessible for guest accounts. Better approach is via SPFx, and accepts this requires coding skills iso no/low-code.

SharePoint Governance complicated, due deviation in permission handling within modern site templates

With the introduction of Modern Sites, Microsoft added an additional layer in the permission handling for SharePoint Online sites: via Office 365 Group (soon to be renamed/branded as 'Microsoft 365 Groups'). Below that new level, one can still authorize within the SharePoint site itself via SharePoint Permission Groups. And to make the story even more confusing: not all 'Modern' sites are equal wrt this new Permission model. In a Modern Communication Site there is no notion / connection to an Office 365 Group.

Comparision Permission Handling + Management within Modern Communication Site vs Modern Team Site

Observations:

1. In a Modern Teams Site, site authorization is delegated done via Office 365 Group.
   1. The SharePoint Member permission Group has as single member the Office 365 Group ‘Members’
   2. The SharePoint Owners and Visitors permission Groups are both EMPTY
   3. Instead, the ‘Owners’ responsibility is assigned by having the full O365 Group Owners as SCA
2. In a Modern Communications Site, site authorization is still on named accounts level
   1. The SharePoint Group has as members the named accounts of persons in the role
   2. And only the person that on site provision/create time was identified as ‘Site Owner’ (in SharePoint Admin portal), is assigned SCA

This deviation is intentional / by design from Microsoft, with justification: "Most often, a communication site has a small number of people with permission to author content and many people who only have permission to read content. Team sites use Office 365 Groups for permissions. Communication sites use SharePoint groups." (source: Teams Site vs. Communication Site: Which one should I choose?).

However, in concrete business usage more and more business users prefer the Communications Site for internal collaboration usage above that of Team Site. Most significant motivation being the page layout options, that make better usage of the available screen estate. And this practical usage results in a governance flaw, as the permission handling on a "team collaboration site" created via Communications Site deviates from that within a Teams site; and the typical business user has no understanding for this.

I'm not alone in my misunderstanding, a good post on this topic is How broken are Office 365 SharePoint permissions?.

Opt-In Modern List Experience on Communication Site obstructs upgrade SPFx app via UI

An approach to upgrade a deployed 'App for SharePoint' is to open the site that contains the AppCatalog (either tenant, or site collection with own app catalog) in a browser, go to 'Site Contents', and double click the App. In the 'About' dialog it will then present the option to upgrade. When the site is in Modern List experience, this approach is hampered: also the 'Site Contents' view is then within Modern View; and the available options there for any App are limited to 'Monitor' and 'Remove'. Microsoft is aware of the issue, and for now advises to apply a workaround: in the Modern 'Site Contents' view, click in the lower-left corner on 'Return to classic SharePoint'. This results that on the fly the 'Site Contents' view is rendered in classic mode, and the approach to upgrade App are available for usage. However, it turns out this workaround is only available for Modern Team sites, but not for Modern Communication Sites. Direct cause is that Communication Sites by Microsoft Design do not have the 'Left Navigation' (see Modern SharePoint Sites navigation options). And by Microsoft Design flaw this lack of left navigation is propagated into application and listview pages, including 'Site Contents' (Communication Site - Left Navigation Missing in Lists / Libraries). This leaves as only workaround for Communication Site to support upgrade of (SPFx) Apps interactive through the SharePoint UI, is “Opt out of the Modern list and library experience” for that site; at least for the moment when you need to upgrade any of the (SPFx) Apps in the (site) app catalog.

Note that the non-UI approach of upgrade via PowerShell (Update-SPAppInstance)is not hampered by the Modern List Experience.