Drowning in Config Profiles! How Do You Keep Your Jamf House Clean and Organised?

I would say I use both of the methods you mentioned. I create global profiles wherever needed and useful, but if possible I try to be as specific as possible.

This makes it a lot easier to scope things more granular. But also increases the amount of config profiles and thus maintenance.

Categories help a lot, but I also try to use keywords at the start of the profile name with the specific payload used, e.g. "Restrictions: Global App Blacklist", "WiFi: XYZ" or "Certificate: XYZ".

But I'm sure there are others out there with even better ideas ;-)

I am the same, Categories get you some sense of order. Key words in the name of the profile also help out and tidy things up. Also the same where I have some profiles that do a lot in one, but others will only do one thing - PPPC profiles and Approved Background services are all single items. I only grant just enough access when it comes to these.
And no you really do not want to look at my Configuration Profiles list, there is a lot in there. But it is all fairly self evident as to what it is.

For me, this is the list of things that keep me sane.

1. Naming conventions - Ensure your Configuration Profiles, Policies, Scripts, you name it all have logical naming conventions that tell you what the thing does or is for when glancing at the name alone.
2. Categories - Have lots of categories that make sense.
3. Keeping unrelated payloads separate - Rather than having one master configuration profile, I will have several smaller ones for a single preference domain. If the payloads in a Configuration Profile are not directly related I split them up. This makes it easy at a glance to see what configs you may be missing if naming conventions are down, and makes troubleshooting simple as you are only dealing with a few payloads. This also spreads in to policies, don’t have unrelated packages or scripts in a single policy.
4. Consistency - once you come up with conventions, stick to them, document them, and make everyone else follow them.

@gmihailo As @LK90_2 and @PaulHazelden have already replied you'll find the need for both broad and specific profiles. One thing to watch out for is that the current Jamf Pro Configuration Profile Restrictions payload does _not_ play nice if you're looking to deploy multiple profiles using nice because it doesn't only include the keys you want which is problem because if you include a key in multiple profiles which one will "win" is "undefined". You'll want to look at using the Application & Custom Settings with the schemas from https://github.com/Jamf-Custom-Profile-Schemas/ProfileManifestsMirror to create your restriction configurations.

An example of what using the custom profile approach provides which isn't possible with the standard Restrictions payload is deploying one broad profile with standardized Software Update settings (e.g. auto check, auto install security updates) and also having group specific profiles with different settings for macOS major and minor updates.

Trying to think of other things not mentioned already. 

I'd make use of the Description box. This helps the customer, you, and other admins understand what the configuration profile is all about. Helpful if you leave the organization, and the next person has to pick up the bread crumbs. 

I also find it useful for myself because I forget about the work I did myself!

On another note, depending on the scenario, it might be useful to not stack configurations into 1 master monolithic profile when possible. When you break out the configurations into smaller pieces, it's easier to troubleshoot, update, and make changes. I found this useful for iOS and macOS.

Lotsa great replies above...using most of those as well.

Just as I think was said, be careful about profiles that could conflict.  More restriction is the default if you have two battling for power.

Naming and Categories rule the day, and even that is not always enough to not wish for a cold Martini!

I don't know if you've entered into the CIS stuff yet, but hold on, there are dozens more profiles, and this is a bear to sort out with existing profiles that likely cover many of them in one way or another. 

If you haven't done so, try this:

LowProfile Utility 

Originally when I started out with Jamf I had one profile that did 70% of what we needed and then a few other profiles that I used for various other things.  During our Jamf Jump Start we were encouraged to seperate our profiles as much as possible so we definetly break it into smaller specific profiles.  I'm glad we did that as throughout the years we've had to change some of them extensively and rather than having one big profile change it's just been the ultra specific ones that have changed.

Some really solid replies here that I truly appreciate. Lots to think about. Coming from a mostly Windows environment and predominantly SCCM there's still lots to learn :)

CIS / E8 is next on the list actually! :)

+1 for what @AJPinto says.

• Leverage the categories that are in Jamf Pro.
• Keep a consistent naming convention, for example: [restriction] Block iCloud Drive 
• Split up your profiles as much as possible.
• Fill in a clear description for future reference.
• Be consistent.

There is a good one I forgot to mention, version control. Put something at the end of the profile name like V1, V2 or what I do 2505 (YYMM and if necessary YYMMV1, YYMMV2).

This way when you have a device bugging you know at a quick glance from the inventory record, or System Settings Profiles if the device has the current Configuration Profile or not.

Another thing to consider when creating Configuration Profiles is that deploying a profile to a version of macOS older than the version that added support for any setting keys in the profile will at best result in the setting being ignored when updating to the applicable version of macOS, or the profile may fail to install. An example of the former is the addition of automatic Wi-Fi MAC address randomization for macOS 15.0 along with the associated DisableAssociationMACRandomization key for Wi-Fi configurations to disable that behavior. You could apply the key to a Mac running macOS 14 where it was unknown and would be skipped, and since MDM settings aren't re-evaluated on macOS updates it would still be ignored after upgrading to macOS 15 until the profile that was used to deploy it was removed and re-installed (much to the annoyance of orgs where MAC address randomization would prevent Macs from connecting to their Wi-Fi networks).

For profiles that have payloads like that I usually create a Category specifying the initial version of macOS they'll be supported on (of course I have a scope exclusion in effect for non-compatible versions of macOS but the category labeling is more obvious when viewing the profile list in Jamf Pro).