Ajay Hinduja Geneva, Switzerland (Swiss) How do I deploy an app to all managed Macs using Jamf Pro?

That would depend on a few things.
If it is an App purchased through the Apple Volume purchase system, then you would be pushing that out from the apple Apps section, either as a forced install, or as a Self service item. With the possibility of forced updates from there.
Similarly with an app that appears in the Jamf Apps catalogue.
If it is an App that is not in the AppStore, then you would be uploading it to the Jamf server and building a policy for it. Again the choice of deployment is available, either a forced deployment or a Self Service one.
I tend to only use custom triggers when I have a policy I want to set off via a script. I have a script that will set off a sequence of policies in an order I set in the script. It removes the problems of policies running in alphabetical order.
Self Service or forced is a debate you would have in your company. I am in education and have Lab machines, which I force all installations on them. I also have Laptops, and these I use Self Service for distribution on these, I let the staff choose what and when they install.

This is entirely up to your needs, there is no right or wrong way.

The nuts and bolts for AppStore Apps:

1. You need App Licenses from Apple Business Manager or Apple School Manager
2. You need to add those App Licenses to your MDM of choice.
3. You tie the app licenses to the AppStore App policy and scope it out to your desired devices.
4. You set the trigger based on your needs, self service or install automatically.

Note: If you dont have licenses for the Apps, the users will be prompted to open the AppStore and buy the App (free or pay, both need a license). You need 1 license for each device within scope, regardless on if the device has or will have the app installed.

Note2: AppStore apps cannot be version controlled at this time. The most recent version will be what is installed, and updates are configured in the AppStore App policy, again deploying the most recent version only.

The nuts and bolts for Custom Apps:

1. You need to package your source files, using composer is the most straightforward way to do it if the developer does not furnish a package themselves.
2. Make a policy, add the package as a payload and set the scope.
3. Define the trigger, Self Service, Recurring Checkin (force it).
   1. Best practice is only one trigger per policy. If you want or need multiple triggers, have multiple copies of the policy.

Note: Many Applications are presented by the developer as packages, DMG’s can also be deployed but package is the preference in most situations. 

Note2: Many Applications have auto updaters built in, for those apps you just need to update the packages occasionally to insure you are not installing an ancient version full of vulnerabilities. For all other apps you want to regularly built new packages and deploy to keep the apps up to date. 

Note3: You can make smart groups looking for the app to be installed, then set that as an exclusion to the policy. From there set the trigger to run on recurring checkin with no device limit, that will cause jamf to reinstall the app if it is ever removed. You can go a step further and have the smart group target a specific version of the app, and change that version after you update the package to cause the policy to rerun and update the app on devices.

When and where possible use Jamfs App Catalog.