Hallo Alex! At the moment there is only one way possibility: A user is added, modified, deleted _FROM_ aMember database and not otherwise. For instance if there is a plugin_registry, in which all necessary data is stored, that would serve the purpose the best. For instane aMember knows exactly what are the system fields. Also the additional fields are also defined and amember knows exactly what are thosefield names in amember database. What is not there is a database field mapping! So if there is a mapping table like amember_field_mapping then following could occur: Each and every plugin could have a configuration in the pluginname.config.php all those field mappings of additional fields. Those fields would then be added in the amember_config table. The biggest advantage is that this would generate a two way system of plugin architecture, where all the User_Data available in the integrated database for e.g. joomla_plugin.php could either _GET_IN_ or even _GET_OUT_ of that database. Hence the imports from joomla_plugin.php would be without any problem. The fields are known of the default joomla installation. They could be well mapped in the amember and then could be imported. Further, if there are signup problems, then the signup could also be used of a program like joomla, xoops, etc and then would be inserted in the background into the amember. All those possibilities would be open if the field mapping is integrated into amember, which i find it really very helpful for all the users of amember.