Morning all. I've had a look at multi-schema and seen it isn't properly supported yet. I've got a work-around for the time being and just wanted to check that it's not likely to break on future updates (say 70%+ confidence it'll be fine for the next 6 months 😉 ) 1. Have a generic "shared" schema which contains all traits for all schemas 2. In the shared schema include a "true_schema" trait 3. Request registration flow server side. Pass a configured set of "schema nodes" which is basically [{ node_id, visible, value }] a. e.g. /register/business (SAAS business user account) might return [{ node_id: 'true_schema', visible: false, value: ''business_v0" ] b. /register/user (SAAS enduser) would return [{ node_id: 'business_name', visible: false, value: 'any default that passes validation' }. { node_id: 'true_schema', visible: false, value: 'consumer_v0' }] 3. Add a after registration hook which checks the true_schema trait, removes traits that aren't relevant for the identity and updates the identity schema. (this is the bit I'm hoping never breaks) There are a lot of limitations, but for my use case this works as needed as both user types have to confirm emails before being able to log in. I am also fine doing flows server side.

Cool idea Mike 🙂

yeah that would be ideal. I just wanted to check the work around for now doesnt ring any alarm bells, but sounds like it's all fine 👍 thanks

I was thinking GET /selfservice/login/init?schema=123

ah yeah that would be perfect. but for log in it seems to "just work" as-is. registration obviously needs the adjustment. not sure on the other endpoints

sorry yeah, i wrote it on my mobile and did not give it a lot of thought, it should be registration not login :)=

ok thank you!