The Munki wiki has a full list of Supported Pkginfo Keys. At some point, you should explore and understand each one. If you’re at the beginning of your Munki admin’ing, though, you may want to at least consider these to start out with. You can edit most of these in MunkiAdmin by double-clicking the item (just be sure to save changes afterwards), or you can edit the pkginfo file directly with a text editor like BBEdit (just be sure to run makecatalogs afterwards).
unattended_install
I would highly recommend using this key on any item you have in your Munki repo that doesn’t require a logout or a reboot. Installing or upgrading items without having to bother your users is a beautiful thing. And, yeah, don’t worry about Munki trying to install an application while it’s open (e.g., a user has Chrome open, and it won’t unexpectedly quit so Munki can install an update), because Munki has blocking applications.
name
This is something Munki sees but users don’t. When your users see software you make available in Managed Software Center, they’ll see the display name or the description, but they will not see the name, but the name is something you, as the Munki admin should definitely pay attention to—that is how Munki decides X version 2.0 is an upgrade to X version 1.9, because it’s named X.
requires and update_for
You can build dependencies in your Munki repos, so if you need a Microsoft Word item to depend on a Microsoft Office license item, then you should either make the license item part of the requires key of the Word pkginfo (any time Munki installs Word, it will make sure the license is installed first) or make Word part of the update_for key of the license pkginfo (any time Munki installs the license, it will also install Word afterwards).
This can also help if you want to deploy a .mobileconfig profile to accompany an application.
OnDemand
The OnDemand key means that the item can be installed over and over again, and Munki won’t care if it’s already been installed. This key makes sense only if you have the item as an optional install in a manifest. If you make an OnDemand item a managed install, it may get into an install loop.
This can be helpful for any nopkg (script) you want people to run over and over again without regard to whether the script has ever been run before.
force_install_after_date
It’s a good thing to know about, but I would be very judicious in using this pkginfo key. It will give some warnings to users but will essentially force them to log out and/or reboot to install whatever you’ve deemed needing a force install. Some corporate environments might force this sort of thing once a week or once a month, but at a school, I can’t imagine using this more than twice a year. More details here.
preinstall_script and postinstall_script
A preinstall_script is any script you want to run before the item installs, and a postinstall_script is any script you want to run after the item installs. Keep in mind that everything in Munki runs as root, not as user. Bash and Python are popular scripting options for Munki admins, but scripts can be run using any environment/language you know exists on the client.