What is the Jamfadmin password?

You should not need it. The Jamf Pro server keeps track of the password, but it's hashed in the db for each computer record, so there's no way to see it there.
If you need to, you can set up a policy to deploy out to machines that will reset the management account password to something you know, or just something random (which would mean you would not know it). There's a policy payload to do that called "Management Account"

I see. The issue is that the jamadmin user was deleted after running a policy but the jamfadmin home folder is still there. I was going to recreate the account and trigger "use existing home folder" from the system but I have to provide a password. I guess I can use any password then sync it with the JSS?

Why not just delete it and run the quickadd pkg to rebind the machine to the JSS, it will create a new admin account for it's own purposes.

Are you saying the jamfadmin account appears in the /Users folder? The hidden management account for Jamf Pro doesn't keep its home folder there. If you're seeing a folder in /Users, then it's likely for some other purpose than Jamf's use.

@talkingmoose No, the home folder is in the hidden location but the user profile is gone. All of the user profiles were gone after the policy ran but the home folders remain. I recreated the visible account by using the same exact name which gave me the option to use the previous home folder. Just thought could do the same with the jamfadmin accountant not mess anything up.

@Look Are you saying to delete the home folder or to delete the machine in Jamf?

@Vernaf Are you saying that there is a hidden home folder in /private/var/ for the jamfadmin account, but no record in dscl, like if you do dscl . list /Users it doesn't show up there? Did this policy get rid of other critical hidden accounts? While a system could survive if the hidden jamf management account gets removed, it's likely going to experience some problems if other hidden system level accounts got removed as well.

All that said, I would do what @Look mentioned and just deploy a QuickAdd pkg to your machine(s) using the recurring check-in trigger, which gets called by a LaunchDaemon, so it doesn't need that jamf admin account to work. Be sure when you create the QuickAdd in Recon.app that you specify that it should create the account if not present, and choose for it to be hidden. I would not trying manually fixing this as there's no guarantee doing it that way that the JSS will pick up any new password for that account.

@mm2270 Yes, that's exactly what I am saying. Not sure what else was gone except that all the users in the dslocal subfolders were wiped. Ok, I'll try the QuickAdd in Recon.

In Recon, the options: " Ensure SSH is enabled", "Sign with..."
"Use existing site membership, if applicable"
- Should they be checked?

For the SSH option, only if you want to ensure SSH is enabled on the Mac. You can specify that only the Jamf management account have SSH enabled access for it, in case there is a security concern around that.
As for the "Sign with" option, generally no, unless you have a developer certificate that you want to use to sign the QuickAdd pkg. Otherwise it's not needed.
As for "Site membership", that just means if a Mac is already enrolled into a Site when the pkg runs, like in this case where you are re running a QuickAdd, then it will enroll it back into the Site it was part of before. If you don't use Sites, then it can be left unchecked.

So in all 3 cases, you will need to decide if you need those on. Do you recall what you used when you did your original enrollments? If possible, go back and look at what you used the first time around.