Hi there @GetCart3r. So, when you did your capture in Composer, did it capture some items in a location like /Users/<username>/Library/ etc? If so, those types of settings can be applied to existing users and even new users, but it requires Jamf Pro for deployment, because they need to be built as a DMG (disk image) and then an option called "FEU" or Fill Existing Users has to be enabled for the package. Once it gets pushed from Jamf, it uses that <username> as a wildcard for any other home folders that exist in the /Users/ path.
But if you take that same Composer source and build it as a PKG installer, whether it's pushed from Jamf Pro or just manually installed, it's just going to create a folder with whatever username is in the source and drop the files there. It won't see any existing user folders in /Users/ like with a DMG format.
OTOH, you could do what some other people do and create a script that copies the relevant files in the source into the proper locations. As long as it's not a lot of files to copy and just one location to copy them to, it's not very hard. It has the advantage of allowing you to build the package as a PKG and also let's you use the installer outside of a Jamf Pro workflow.
Lastly, I'd be remiss in not saying that these days the best way to manage settings for applications is with Configuration Profiles and not deploying plist files and other items to users. It's much more reliable, doesn't require a package or rebuilding packages each time you need to adjust them, and has the advantage (if you consider it to be one) of forcing the settings and in many cases not allowing end users to make changes or remove the settings after it's applied.
