I think first it’s useful to take a step back: Daml is really designed for distributed, open-world networks. In an open-world setting building things around universal statements of the form “all templates”, “all parties”, … are usually problematic and are going to result in apps that cannot coexist nicely.
listKnownParties can give you is a temporary snapshot of all parties known to the participant (which does not necessarily include all parties on the ledger in distributed settings) and even that requires admin claims which are not available to a trigger.
So instead I’d recommend to change things around:
Rather than have the trigger read the parties from the party admin service, store the list of parties the trigger should interact with in a config contract. This contract can look as follows:
triggerParty : Party -- The party your trigger is running as
otherParties : [Party]
key triggerParty : Party
The trigger rule can then look for this contract and read the parties from that.
You are completely free to handle creation of that contract and updates how you want. This can range from a manual creation once to a process that polls
listKnownParties periodically or something else depending on your usecase. I’d recommend against relying on the hint for this though. First, you cannot read the hint from the party management service, you can only set it on allocation. Second, it’s handled differently by different ledgers which makes it hard to write a portable app. Instead try to keep track of parties as they are allocated and use the resulting party ids directly.
Finally, depending on your usecase you might also be interested in multi-party submissions Roles in Daml - Introducing Multi-party submissions. I’m not quite sure I grasp what you are trying to achieve but it sounds like having one party as an observer on all contracts you want to share and then providing
readAs claims for that party to everyone might also work.