Roles are a reserved folder type. Contacts can be shared into these folders (assigned a role), but they MUST have an associated user account prior to the Role share. Even though roles can be imported, Role privileges and permissions are not assigned through the imports.
Example
Because of the nature of roles (organizations and folders too) and the amount of dependencies/configuration that can be associated with them, the behavior of the importer would allow them to be created, but not deleted during an import. Even if they are removed from the feed, a role will persist. They can, however, be deleted through the GUI as would normally be the case.
So, if an import contains the role once, it will be created, and it will stay in the system. However, subsequent runs with the same Role and a different ParentOrgId would cause the role to move under a new org.
Because roles will not be deleted, you must populate the ParentOrgId column with the correct value for this role, or any moves made in the GUI will be undone during the next import.
For more clarification, we've listed some examples below and runs through most of the typical scenarios that come to mind.
First Import
ParentOrgId|RoleCustomerId|RoleTitle
GAL| RoleId1|Role1
GAL|RoleId2|Role2
Role1 and Role2 are created in the root org (customerId = 'GAL')
Second Import
ParentOrgId|RoleCustomerId|RoleTitle
GAL| RoleId1|Role1
Even though Role2 was removed from the feed and is not currently being managed by the import, it persists in the system. This import effectively doesn't change anything, as Role2 will not be deleted, and Role1 (currently the only row in the file) already existed.
Third Import
ParentOrgId|RoleCustomerId|RoleTitle
GAL| RoleId3|Role3
In this import, Role3 will be created, but nothing will change with Roles 1 and 2. The import is not currently managing them, but as Roles are not deleted in the system, the only change here is the addition of Role3 to the root organization.
Fourth Import
ParentOrgId|RoleCustomerId|RoleTitle
OrgId2| RoleId1|Role1
GAL|RoleId2|Role2
GAL| RoleId3|Role3
In this example, Role2 and Role3 will remain unchanged, but the import will attempt to move Role1, as its ParentOrgId has changed. In this scenario, nothing happens with 2 and 3, but 1 will now be under OrgId2, as long as OrgId2 exists.
Some more examples follow with regard to moving roles. Please assume we are starting from scratch again (first import):
First Import
ParentOrgId|RoleCustomerId|RoleTitle
GAL| RoleId1|Role1
This import will create Role1 under the root org (OrgCustomerId = 'GAL')
At this point, please assume the import has completed successful and that role was created under the root org, but before the next import someone moves Role1 under a new org (let’s say OrgId2 again). So Role1 now has an OrgCustomerId = 'Org2Id'.
Second Import
ParentOrgId|RoleCustomerId|RoleTitle
GAL| RoleId1|Role1
Since the same feed was run, and this row specifies that the parent of Role1 is 'GAL', Role1 will move back under that org, effectively undoing the move made in the GUI. The correct thing to do if you want your feed to be cumulative would be to control the movement of these roles using the importer as follows.
