Ability Members to register on their own

[Emengkeng]

New members should be able to register on their own. Then the admin will see these members an he/she can either accept it or reject the application

[stephenyeargin]

That's an interesting idea. We wrote this as a supplemental service to a much larger membership database in Salesforce. We would take exports specific to our chapter to load into this platform in order to power our email lists and allow folks to update their own membership records. It has since been expanded to track donations as well as facilitate text message broadcasts. At its core, though, it has always been meant to manage a subset of a larger member management database.

It might be something to explore in the future, though. One approach would be to build out an API that would allow a separate application the ability to create/read/update/delete member records.

[Emengkeng]

If the option of separate API is used , this would mean creating a different database for members to register on their own. Which means the will be two different Database table. If so, won't that cause Redundancy?

[stephenyeargin]

Not necessarily a separate database, but a separate application that would write to the API to create the member.

sequenceDiagram
    External Form->>+API: Posts new member
    API->>+Member Directory: Validates submission
    Member Directory->>+Database: Saves record
    Member Directory->>+API: Reports success/error
    API->>+External Form: Reports status

Loading

[tacman]

A variation on the self-registration idea is an "invitation" table, where admin can invite a user to join, and users can request to join. In both cases, the status and basic information would be stored in the invitation table, until either the user accepted the invitation, or the admin approved the invitation request, at which point the member and user records would be created.

Actually, the user record could be created without permission, since really the core entity is "Member", not User.