How many policies for each Application?

Well.. it depends.

@grahamrpugh has documented workflows with 7 policies per title.

Whereas I would have 3 max via jamJAR

1. self service
2. Install automatically or update it installed
3. Uninstall

4. two

5. two

I've got more now:

1. Untested version (Self Service)
2. Install prod version via trigger
3. Self Service install prod version
4. Self Service update to prod version
5. Auto-install prod version
6. Auto-update to prod version
7. Uninstall by trigger
8. Self Service uninstall

Our main installation method is via the Self-Service. For simple cases I have two policies: "install" and "remove". Some apps and configs get installed when a device joins a static group. In that case we add a custom trigger to the same policy as used for the Self-Service.

Then there are the products that require whitelisting kernel extensions, these need a few more policies:
- install on macOS < 10.13.4 (Self-Service, now obsolete)
- request the install (Self-Service, for macOS >= 10.13.4) - whitelist kext (when MDM sees flag that user requested install, but kext is not yet whitelisted)
- install product (when MDM sees that kext is whitelisted)
- remove (Self-Service)

What are you doing different in (un)install by trigger and (un)install by Self-Service that you need extra policies for them?

Just came across this thread and wanted to add my method. I figure the more people share their processes, the more we can all learn from each other! I currently employ six policies:

1. Main - contains the package and the policy trigger
2. Automatic Install - for apps that we deploy automatically
3. Self Service - even if we deploy an app automatically, I like for the user to be able to re-install from Self Service
4. Update - A Self Service policy the lets the user take ownership for updating their apps
5. Patch - Installs the latest version of the app at login so that it gets it when they reboot
6. Remove - just what it says on the tin

Similar to what @mschroder mentioned, I would remove the Enrollment Complete trigger and instead use a Custom Event trigger setting and simply call that trigger in a script during enrollment. Meaning, have a single policy that gets called at Enrollment Complete that has a script which runs all the other policies by their custom event triggers.
That way the policy would only get called during enrollment when that trigger is specifically called. This eliminates at least one of those separated out policies, since the same policy can double for Self Service, as long as you make sure the scope is set correctly. Both Self Service and Custom Event can be considered as "user initiated" if you think about it, just that one is called from an app and the other called from a script or Terminal.

Unfortunately you will still end up having several other policies for that same application if you want to have things like uninstalls, silent installs that get triggered based on Smart Group membership, etc. Can't help much there. Given how Jamf Pro is designed it's inevitable that you will end up with a number of different policies all installing (or uninstalling) the same product but under different circumstances.

It would be nice actually if Jamf figured out some easy to use way to make installs & uninstalls into one policy, as in, if the app is installed, automatically (or via a checkbox option in the policy under the Self Service tab) show an "uninstall" version of that policy in Self Service. This would be a nice feature as it would eliminate a common reason why we need more than one policy per application title. I actually think there's a rather old Feature Request floating around here that asks for that in fact.

I think the thing to remind yourself is what is expected from your organization in terms of deployment for testing and production. Some organizations put their trust in IT allowing for them to cater the flow to what's easiest to put together. Others, like my own, we're required to email people IT Alerts that includes scheduled times for specific computers at certain times. Due to this I have a few more policies per application than some others might as the "auto" policies are split up for different areas that get deployed on different days.

While it creates a number of policies and groups, the only thing you really have to touch once it's done is the version number in the smart group to deal with updates.

At the risk of going off topic I would be curious how people using this method are deploying something like Creative Cloud. Are you splitting them into individual applications with a few policies for each one or do you deploy as one or a couple large packages? Do you update using this policy system or something like RUM?