If your org hasn’t already set up a dev server with Jamf, you can request one for free. Your Customer Success rep should be able to help you with that. Testing in a completely separate environment is going to be the safest thing.

If that’s not an option for whatever reason, be super careful with your scoping when testing on your prod server.  If you’re cloning policies and profiles to play with copies of them, the original scoping will be included in the new copy - be sure to remove the original scope(s) from your test copy and just scope it to your test Mac.

You might also consider making a Test category in Settings and assign your test stuff to it.  Adding “Test” or some such to the name of your test items can also help with clarity.

Welcome to the Jamf family!

IMO, there are very few uses for “Sites”. One is for testing. You can use that if you don’t have a dev environment yet. But to echo @ThomM, its free.

Yeah Sites would be another way to test on the prod server, but much like scoping you’ll want to be super careful about which Site you’re looking at when doing stuff.

Another trick I picked up from my last Jamf course was to set Dark Mode on your prod server and Light Mode on your dev server (or the other way ‘round if you prefer) to give yourself an easy visual aid for which environment you’re working in.

Your companies Jamf Pro license comes with a sandbox (text instance) in addition to your prod instance. Keep all your testing inside the test instance. You can also request a developer instance which is in the beta lane. 

Fully configure your Jamf sandbox if its not already and enroll a test device or two. Then go to town with no risk of impacting prod.