That doesn't sound normal to me personally. Although I'm not a good candidate to confirm or deny the behavior since a) we don't use any login policies here and b) we are still on version 8.73 in production.
That said, I think the login hook scripts that the jamf framework installs should be seeing whatever policies are triggered by "login" and running them, all. It doesn't make any logical sense that it would only run one each per login. The only thing I can think of is that the behavior when using a once per user setting is a little weird. See this feature request for what I mean.
https://jamfnation.jamfsoftware.com/featureRequest.html?id=45

But I'd say this is likely a bug or not expected behavior. You might want to check in with your account manager to get their thoughts, or file a bug if this isn't the way it should be working.

As for a workaround, you could do something like craft a simple script that would call each policy one by one by their policy IDs or a manual trigger. Then in your login policy just run that script instead. That should then cycle through all the policies that the script is calling.

Thanks @mm2270

I plan to try the workaround you mentioned, can I just clarify that I am doing this correctly?
- Create a script with multiple (jamf policy -trigger customTriggers), upload this script to casper admin and attach it to a policy to run at (login) execution frequency (per user)
- Once this script runs, it should essentially trigger the customTriggers container with the script?

Thanks a lot.

That's basically it.
Just one thing I'll mention is that hopefully you're working with http enabled Casper sharepoint(s) since I believe there is an issue if you try to run multiple policies from a script with AFP/SMB share point(s) Specifically, since the share is mounted to run the script, when it attempts to run the actual policies being called in the script, it will have trouble since it'll try to mount the share again and will fail.
The problem shouldn't happen when using http/s on the distribution point.

The other thing is, you can make this script kind of modular in that instead of hard coding the manual triggers or policy IDs, you can pass them to the script as parameters, so $4, $5, $6 etc can be entered as the policy IDs/triggers that get passed to it. That way you can use the same script for different login policies if need be, Make sense?

It does and makes perfect sense, Ill need to play around with the scripts again as they work if I run them on the client manually but not quite working the above way.

You mentioned HTTP File share, we do have one setup as well as an internal SMB File share. However, I noticed that you cannot specify which File share the script runs from like you can do with packages. If you have HTTP enabled, does it automatically pull it down?

Thanks again.

Just a note, we have file share distribution points and have no issues running a new trigger policy while the share is already mounted by another policy, so having a policy script invoke additional policies should not be an issue.

It's true that this did not work in 8, though.

@mm2270 sorry to trouble you with another off topic question but I'm trying your above method by using an attached script to run a policy which is then triggering the below script, however it's creating the Applications folder in the root's directory rather than the current logged in user. Any ideas how I can improve this so that I can reuse in future?

For example, I am try to create a folder in the users Application folder;

#Find current user
U=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }')
echo $U" is the current user"
#Create directory
mkdir /Users/$U/Applications

Thanks in advance

Scrap that crappy script above!

mkdir /Users/$3/Applications

Did that trick