Hi Max,
Regarding the first point: yes, kicking off an automated propose/accept workflow starting by automatically creating contracts via frontend/React code when the user logs in is a decent pattern to employ. Triggers are not able to react to the existence of parties directly, so you’ll indeed need to create a User template and have it get created for each party when they log in to the UI.
The nice thing about this is it provides a natural spot for a more specific new user onboarding experience for your application. Suppose you want the User template to have fields for name, email, phone number, favorite color, or anything else. The UI could expose a form displayed to new users to collect this information, which the user can provide when logging in the first time. Then of course automations have a convenient way of listening for new signups by streaming & listening for User contracts - it’s a nice “win-win”
To the second question:
As @alex.graham explained, you might not need per-party triggers. However, if you really needed them…
It shouldn’t be necessary to hardcode party IDs in the trigger code itself. The trigger gets launched with the authorization of a specific party at runtime, so you’d have one trigger instance running as admin, and other instances of the same trigger running as end-user parties. The recommended approach on Daml Hub is to utilize the UserAdmin party as a global admin/operator, as its ID is well-known and publicly discoverable.
To instantiate a trigger deployment as a different party, you can use the same idea of “auto” deploying it from the UI codebase on the end-user’s behalf, by making an HTTP request to a Daml Hub API endpoint.
You could achieve the same thing with the @daml/hub-react library, which now ships with the newest create-daml-app templates. See the documentation for that here