Don't want to defer any more

There may be other methods, but duplicating this policy then removing the deferral options and setting it as a self service policy, should work. You could assign to that specific device/user or however you see fit.

That is a great and simple idea. But since the first policy is not yet applied, wont it bother the user for upgrading again since its only deferred ?

With that, you could configure the self service policy to only be available if the initial policy is completed. You then may have to consider adding to the scope of the "deferrable" or second policy to include groups or devices that have completed the self service policy so it does not run again.

So I set a software policy named Software Title - Main to have a custom trigger and put it in Self Service. Then I create a second policy that is Software Title - Push that just runs the process jamf policy -trigger customtrigger and checks in daily, and excludes people with the version that it's updating too. But that way the policy is in Self Service and they are getting prompted for it.

The other big advantage of doing it this way is that if you need to make a change to the way a policy works you only need to change it in one place.

I built a static Python code tool that automatically patches apps if the app is not running and it prompts users on a weekly basis if they keep the app open. I leverage full end to end automation with AutoPKG and JSS Importer. When a new package gets published to my jamf cloud tenant, the static code handles all the policies and updates with out me changing a single thing. This is the balance I created between UX and security patching.

You should always patch your apps, because it is not that hard to do. It is also a very bad story to tell your partners, customers, and other Orgs you associate with that you do not patch your endpoints. I have had jobs too, that have always put too much emphasis on allowing users to choose their own software and versions. To me this is very much a horrible practice, because would you tell your business partners and customers you don't patch zero day vulnerabilities to your fleet? If I was told that, I would lose a lot of respect and trust to any Org that allowed this.

Unfortunately, Jamf Pro doesn't do this well without a ton of labor intensive practices, or if you want to use Jamf Patch it is even more work, and you are blocked by Jamf releasing updates to their patch feed. Alternatively, you can use Patch Community Server but that means you must manage another piece of infra to do something that should just be built in. I did write this Feature Request that I really hope Jamf takes seriously, as it addresses all these issues.

I haven't built many packages manually in the past 1.5 years at my current gig. My first month there I built this framework out because I wanted to put automation, engineering and security first, but also have a decent UX that is not that disruptive to employees. In fact, the only manual ones I build are special cases and some cannot be easily automated (like behind an auth wall for example). Those packages also only take a few minutes to build so it is no big deal. Looking at the numbers from 2019 I delivered 100s of updates, with out me doing a single thing except allowing my code to do the work for me.

Here is my GitHub, and this has been running in my prod env since January 2019. It may not work for everyone, but it has worked very well for me. It is fully automated, I don't have to go through silly processes or changes, or manual labor to deliver an app update. I don't have to deal with tracking deferrals, or managing flat files to calculate things. I feel all of that is mostly wasted engineering efforts, because in the end you can always just redesign the workflows and you can always write new code. So I personally threw all those concepts and ideas in the garbage bin and started off with this. I haven't had to modify the code much at all and once you build the static code it runs forever, or until something breaks. So, I maybe have only spent a few weeks of actual real world work cycles on this.

If your process or workflow is getting too complex, or you are constantly having to put in effort to make one thing work, then you should always re-evaluate what you are doing and what you are actually trying to accomplish.