The 'Add Account' scrip step provides a method for programmatically adding accounts. However, this only works for FM file accounts and does not work for 'External Server' accounts (oAuth, server accounts).
External server accounts are used for role-based access definition (groups). Groups and members of groups are managed on external authentication servers.
In a single-file solution, adding an external account is not a big deal. When it comes to multi-file solutions, it starts being a hassle by causing repetitive manual work.
A notable asymmetry: an account with external authentication can be programmatically deleted, but not created ('Add Account' vs 'Delete Account').
How do you handle the creation of accounts with external server authentication in multi-file solutions?
What is the rationale behind excluding 'external server' accounts from 'Add Account' functionality?
I can't speak to the rationale. We're big believers in and users of External Authentication, it's one of the reasons I speak about it so much and did the white papers etc.
Most solutions I deal with are not single file, there's always multiple files but I've never felt like the requirement to manually create group external accounts as a nuisance. Roles tend to be fairly static once they are defined so you add them once and almost never have to touch them again. It never felt like hardship or a big missing feature to me.
To add and support Wim's comment.
Without external authentication, if you use the 'Add Account' script step (as we do) you still have to have the Privilege Sets setup in each file and your scripts have to refer to these.
I don't see any difference to this approach to the way external authentication works, providing each file is set up appropriately. Any change to a role would need to be replicated through each file regardless of the approach.
Thank you for adding perspective to the above observations.