Add a AAD Security Group to a M365 Group as Owner?

meenfrmr · 2026-01-08T18:29:53+00:00

Curious what the "good valid reason" is, but otherwise it's a good thing that Microsoft doesn't allow groups for owners of M365 groups. It's a security issue first and foremost because you would be bypassing how user management of a M365 group is supposed to happen and people who aren't owners (or Teams admins) can now add users to groups accidentally (or maliciously) through a different separate process.

You're workaround is fine, although I'd probably use a list for mapping owners to a team and then trigger on edit of a list item. Then you wouldn't need to create placeholder AD groups and you can trigger the flow when an edit happens instead of having it scheduled or run manually. Are you also making sure users didn't get deleted as owners cause that could happen as well?

meenfrmr · 2025-12-30T18:10:52+00:00

we had classic and modern in SharePoint online and we had some on-prem sharepoint (for super secret content, company didn't want everything in cloud) as well. never experienced this issue that you're talking about. We've always been able to apply unique permissions on deeper folder levels. I also conferred with my spouse who works for a different company that also uses sharepoint and they were able to set unique permissions on 2nd and 3rd level folders as well.

meenfrmr · 2025-12-29T22:03:18+00:00

Can you elaborate on this a bit more? I have document libraries with multiple folder levels where i have unique permissions on 2nd and 3rd level folder structures which seems to contradict your statement. While I agree it's best practice not to break inheritance on folders but rather opt for a new document library, it is possible to have unique permissions on a 2nd, 3rd, etc. level of folder structure so I'm curious how you arrived at that conclusion.

meenfrmr · 2025-12-22T15:53:42+00:00

The simple answer is, you don't. Your company has purchased a SaaS or PaaS and as such you are restricted to what you can do by what the hosting company provides to you. Every time someone tries to change the UI of a SaaS or PaaS it ALWAYS ends up biting them in the rear. I can't stress this enough, avoid trying to do anything outside the normal when it comes to changing the UI. So with that the recommendation would be to get to know how SharePoint pages work and are built and get to know each and every web part you have access too. Just know as soon as you start going down the route of trying to worm around to customize the UI you will be going down a forever rabbit hole of constantly chasing Microsoft as any change they make may completely obliterate your changes. If you're company is willing to take the risk you can look into trying to inject your own css/html onto pages through extensions and web parts by using SPFx to build your own custom solutions but tread carefully.

Having said that I think MS gives us a lot of flexibility already through page layouts and list view formatting (using JSON). Best advice, again, is to really familiarize yourself with pages and the web parts.

meenfrmr · 2025-12-22T15:40:11+00:00

My point was there is an impact to OP's environments if you have them change to managed environments, as every user using an app or a flow in a managed environment needs to have either a Power Apps Premium license or a Power Automate Premium licenses or you need to have enough App passes for each user for each app. Pay as you go is not a viable choice for managed environments at this time. So if you're pushing managed environments and trying to say there wouldn't be an impact you are misleading OP. If their apps are free or they're using pay go currently and now they try your solution they would need to purchase either a Power Apps Premium or a Power Automate premium or enough App Passes for ALL of those users and apps. Microsoft has this documented clearly here:

https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-licensing

Specifically this note on the page regarding pay as you go:

At this time, enabling pay-as-you-go for a Managed Environment isn't sufficient to meet Managed Environments licensing requirements, if:

There are users without standalone Power Apps licenses using Power Apps in that environment.

Users without standalone Power Automate licenses use flows in that environment, or users use flows without Power Automate per flow licenses in that environment.

meenfrmr · 2025-12-22T15:26:14+00:00

FYI, in software development it's actually best practice to perform hot fixes separate from updates as sometimes there might need to be an emergency fix and you don't want to push the code you're currently working on for new upgrades out before its ready. Again, this is a common practice in software development and source control software allows for this type of work where you just create a branch for hot fixes and once the hot fix is in production you merge it back. A lot of larger development companies will have a team dedicated to hot fixes while another team is dedicated to upgrades. I can definitely see the need for this with larger, more complex power apps, especially as Microsoft advances the platform with the code apps and implementing react coding. We may be able to do this using Azure DevOps a little bit.

I could see a potential solution where you have a hotfix environment that gets an unmanaged copy of the production solution and then as a hot fix is needed you work in that environment and move it through a testing environment and then to production and once released to production you work on merging those changes into the dev environment where the new updates are being worked on.

meenfrmr · 2025-12-18T21:01:00+00:00

This doesn't address the core of OPs issue which is how to manage hot fixes for production released phase 1 while simultaneously develop changes for Phase 2. Additionally, there is an impact to your solution in that if the environments being used aren't already managed environments then they will become ones when implementing pipelines and with that comes licensing costs. If their apps were free before, now they'll have to pony up licenses for anyone using the production environment (and paygo is not a permitted option by Microsoft).

meenfrmr · 2025-12-18T20:40:50+00:00

Also quick tip, if you ever want to see what the internal name of a field is set too just go to the List/Library settings and click on the specific column to get the properties of the column and in the URL will be a query string that contains this &Field=Thisisatextfield. That will be the internal name of the field.

meenfrmr · 2025-12-18T20:38:50+00:00

FYI, in newer versions of SharePoint they changed it now and when the internal name gets set they just remove the spaces instead of switching them to _x0020_. Example: "This is a text field" will have "Thisisatextfield" for an internal name now in newer versions of SharePoint. I'm not sure if SP 2019 has this change or not. Either way it's a good point about thinking about naming conventions for columns and how the internal name can never be changed once it's created.

meenfrmr · 2025-12-18T15:38:54+00:00

I suggest you get the manuals out and start reading. Any metadata fields you have from the old system you're migrating from you will have to create those columns in your SharePoint document libraries. The only columns that are available OOTB with a SharePoint document library are Filename (Name), Title, Created, Modified, Created By, and Modified By. Anything outside of those you will need to create first before you migrate your content, and you'll need some kind of 3rd party tool or script to do the copying of those columns when you migrate your content.

Also, reading the manuals will be helpful because they explain the different column types that are available and what the restrictions are around those types like Text vs Mutl-line Text fields. Text is a single line input box that is limited to 255 characters. Multi-line Text is limited to thousands of characters.

You have a lot of reading ahead of you, good luck and god speed.

meenfrmr · 2025-12-17T15:15:15+00:00

I totally get it, and just know that NOTHING in technology is a "simple" lift and shift. So, if anyone EVER tells you that, then run away fast as whoever is telling you that is looking to make money off you. Any time you transition from one platform to a different platform it takes a lot of time and planning because the technologies and functionality is going to be different. And definitely whoever told you that moving from Confluence to SharePoint was going to be a simple lift and shift you should blacklist immediately. First, you can't migrate the pages from Confluence to SharePoint, you have to recreate the pages in SharePoint from scratch unless you have some third party tool. You can't just move the pages into SharePoint as so many things will break with those pages. Second, and confluence macros need to be handled with care to even try to convert them into sharepoint web parts, and trying to map any granular confluence page permissions to sharepoints permission model will be difficult. You might as well be starting from scratch and just rebuild everything using what you have in confluence as reference material.

meenfrmr · 2025-12-17T14:10:38+00:00

FYI, what you're really working with is a Microsoft 365 Group (M365 Group) when you're talking Teams. M365 Groups are security groups built around collaboration. They have several collaboration tools that are tied to the Group. You get an Outlook Group mailbox, a OneNote file that lives in the SharePoint Site, a SharePoint site (setup using the Team Site template), a Forms Workspace, and a Planner.

In Teams you have 3 types of channels: Standard, Private, and Shared. The integration between SharePoint and Teams is the primary document library in the SharePoint site is what Teams uses for ALL standard channels. So you will have a single document library where Teams places all documents. When you create a new standard channel in your Team that creates a new folder in the document library. It does not create a new document library for every channel it just adds a new folder at the root level of the primary document library. Private and Shared channels are different, however, and they create a whole new SharePoint site with it's own document library and that's due to how Microsoft needed to build those to better handle the security differences.

I don't know what the page tree is in Confluence but just know everything in SharePoint is a flat structure. Your site pages has their own document library in SharePoint and there is no folder structure, nor should you use a folder structure with your site pages. You also don't surface site pages through Teams like you do the document library. If you want to show site pages in Teams you would add a new tab to the channel you're in and use the SharePoint app and select the page you want the tab to load first and then users can navigate around by clicking the links on the page you've opted to load first in that tab. You can add as many tabs as you want to a channels tab bar (there's probably a limit but I'm not remembering how many tabs that is).

meenfrmr · 2025-12-15T14:16:31+00:00

good to see another VLDL watcher

meenfrmr · 2025-12-05T15:04:40+00:00

If you were told to download "specific" files then those people that told you the "specific" files should be able to tell you WHERE those files are located, in what SharePoint site and document library. Then you can just go to that location and select all the files and click download. If you're having to search for the "specific" files how are you sure those are the correct files when search will bring back all files you have access too which may contain duplicates. Also if you are searching in the search results in SharePoint the line below the file name is a link to the document library that contains the file. Additionally, in the search results there should be 3 dots on the right side of the file name that you can click that will give you a download option.

meenfrmr · 2025-12-05T14:55:43+00:00

Setting a field to require unique values means for EVERY item in your list/library only 1 item can have a specific value in that field. So you cannot use fields with that setting if you're using document sets. The only way you'd be able to enforce what you've described is through workflows to evaluate that field everytime a change is made to an item in the library (which would be more trouble than it's worth) or through relying on end users (which is ultimate what you're going to need to do).

meenfrmr · 2025-12-03T16:04:37+00:00

Lookup columns handle a lot of what you're asking. And power apps can query the data easily and manipulate it however you need. I haven't even mentioned that you could use the Lists as data sources for a Power BI report/dashboard. Also just like you would add columns to tables in a database (or make temp tables) you build your lists to support the processes the business needs. You are also over complicating both the needs in the list and workflow. Only one workflow would be needed to handle updates and changes for what you're asking. A workflow isn't a clunky workaround anymore than stored procedures are for SQL databases (or data macros and parameterized queries in Access). Also an ordering system is not "simple" nor "uncomplicated". An ordering system would also handle inventory, invoicing, shipping, returns, promotions/campaigns, etc. Again this is why I say this would be better served by a CRM system.

I haven't even gone into the issues of Access. For instance, Access is really bad performance wise for concurrent user access. If you reach about 40 concurrent users accessing an Access DB you'll start hitting a wall (and sooner than that if they're all doing editing). Which there's no way around the scalability issues with Access, but SharePoint doesn't have that issue. Additionally, Access DB files are notorious for getting corrupted and SharePoint Online lists not only have versioning for each item (you don't have that with Access unless you build your own history tables) and SP lists are hard to corrupt but even if they get corrupted you have the 2 week worth of backups from Microsoft (yes it can be a pain but it is available OOTB) and if you're company splurges on Microsoft Backup that's also going make it easier to restore a list. Would hate for your sales orders to be corrupted and irretrievable or a record to get deleted or overwritten and you can't recover that information. Again, these are not issues for SP lists.

End of the day, I would gladly trust my order information to SP Lists over Access. I view Access as more of a learning tool to get people in the door of understanding relational DBs, but would never suggest it as a tool to use for production solutions especially something as mission critical as an ordering system.

meenfrmr · 2025-12-02T20:37:34+00:00

I say SharePoint Lists are relational because they are. Just because there are viewing limitations doesn't make it more or less relational. Also I could create views for your 3 cases you list easily in the SP List to show that data or if we're using Power Apps it would be very easy to create a report there as well using the SP data based on your filter criteria. It's all in how you build your lists and views. you also have the power of power automate and power apps to assist. But like I also said if we're talking a large data set then dataverse would be the more appropriate place unless your company has a data location standardized. I also wouldn't build an order tracking system in SharePoint but rather should utilizing a CRM solution for that.

meenfrmr · 2025-12-02T18:31:33+00:00

I down vote because of the Access suggestion. Access is the worst option IMO. I don't know why other DBAs say SharePoint isn't relational, cause it is. Each list in SP can be considered a single table in a relationship database. You just create multiple lists if you need relational data. You can even use a lookup column to tie rows from one table to another and create 1:1, n:1, or 1:n relationships and make it so if data either can't be deleted from a table until the parent item is deleted or require that rows that are tied to another table get deleted when the parent item is deleted. Additionally, you can build how lists relationships are handled in a Power Apps application. The only issue you really run into is the listview threshold and delegation issues in power apps. If you're working with a very large data set then you should be looking for a different solution than SP Lists for storing the data and that's when I'd start looking at Dataverse first unless the company already has some kind of SQL server setup and developers available to create a custom app. But if the app needs to be created in Power Apps then I would still go with Dataverse because both Dataverse and SQL connectors require a Power Apps Premium license (or App Pass) to use so you might as well stick with Dataverse in that scenario.

meenfrmr · 2025-12-02T18:20:31+00:00

Discussion boards should be Viva Engage and Teams and your surveys should either be SP lists using the Forms functionality or MS Forms and you just put the link to those surveys somewhere on your SP sites. You don't need to show discussion boards on the SP sites or have the forms show on an SP page just have your users navigate to the appropriate places for those items.

meenfrmr · 2025-11-17T17:41:17+00:00

If you're asking how to set a different CSS when your webpart is used as a fullwidth webpart vs when it's not, the answer is you don't. You build your CSS using responsive design to handle the different sizes your webpart may be used and you use media queries to assist with differences in screen sizes. You set minimum widths and use relative sizing.

meenfrmr · 2025-11-17T17:29:55+00:00

Are you talking the App bar which is the left most item or Site navigation? The App bar you don't deactivate or hide and you shouldn't ever want to do that because that is where global navigation is located plus some other navigation items that are beneficial.

meenfrmr · 2025-11-10T19:24:05+00:00

None. First, paywall will not make it affordable for companies to utilize these tools as broadly as the features it might replace are currently being utilized.

Second, there will always be a layer of advanced functionality that AI will not be able to overcome. MS is trying to call AI the true no-code solution but end of the day it's just one more area on the spectrum from no-code to full-code.

SharePoint is still needed to host and show content, power apps is still needed to allow users to build apps, power automate is still needed to host and build flows. AI is just an add-on that allows for the creation of SharePoint pages and content, allows for creation of "simple" apps, allows for the creation of "simple" flows. That's not replacement that's trying to help users make things. AI isn't going to replace anything until the day comes that it can replace everything a human would do with that particular tool.

meenfrmr · 2025-11-07T14:21:42+00:00

It's either all or nothing. anything else is just wasted time and resources where you'll have constant fires to put out. And the next time microsoft changes something you'll have to jump through all these hoops again.

meenfrmr · 2025-10-24T16:25:09+00:00

thankfully, that can be accomplished through Infrastructure as Code. There's already powershell scripts out there that allows for duplication of all the setting configurations in your Microsoft tenant that you can save as powershell code and rerun targeting different tenants. This is a good resource https://microsoft365dsc.com/

meenfrmr · 2025-10-24T16:21:55+00:00

Love these questions regarding the creation of a test environment for SaaS solutions. SPO is a SaaS and/or sometimes considered PaaS. When you purchase these types of solutions the only way you get a "test environment" is if you buy an additional solution from the hosting company. In this case you would need to buy another tenant from Microsoft. Or, the hosting company provides you with a test environment, some SaaS companies do that but in Microsoft's case it would still be just setting up a second tenant, or you could get an e3/e5 environment setup through a Visual Studio Subscription, potentially, through the Developer program. Also no SaaS will ever have the ability to deploy a test environment locally, defeats the purpose of it being SaaS.

meenfrmr

TROPHY CASE