User provider
Import and export user and user group data
The User Provider allows you to import and export user and user group data in a more straightforward manner than the Dynamicweb provider allows - this is achieved by abstracting a separation of users, addresses and groups at the provider level.
User data has been abstracted into these virtual tables:
- AccessUserGroup contains user group data. A tree structure is defined by using the AccessGroupParentGroupName field. An empty node means the group is placed in the root of the tree, otherwise we match on AccessGroupGroupName
- AccessUser contains data on individual users. Mapping to groups is done on the field AccessUserGroups which in your import file should be a comma separated list of group names
- AccessUserAddress contains secondary addresses for users. Mapping to the individual user is done on the field AccessUserAddressUserID, which should be mapped to what you have selected as the key value (defaults to username). If for instance you have picked AccessUserExternalId as your key column, then this is the value you would use for column AccessUserAddressUserID.
- AccessUserSecondaryRelation is used for users who can impersonate. Mapping to the individual users is done on the fields AccessUserSecondaryRelationUserID and AccessUserSecondaryRelationSecondaryUserID which should contain either the user ID, username, customer number or email.
Used as a source provider
When exporting user data with the user provider as your source provider, you will have access to a few settings to control which users are exported:
- Export users created or edited since the last export - when checked, the provider checks if the timestamp value in AccessUserUpdatedOn field of an AccessUser record is larger than the timestamp in AccessUserExported - only if so (or if AccessUserExported is NULL), the record is exported
- Export users created or edited after selected date time - when checked, only records with a timestamp in either AccessUserCreated or AccessUserUpdated larger than the time set in the date picker below are exported
Used as a destination provider
When the user provider is used as a destination provider, you have access to much more extensive settings, which give you more control over the user data you import.
First of all you must specify a user key field, which is the field that will be used as the identifier for the record. It determines whether imported user data is created as a new user, or is used to update an existing user. If the e-mail address is unique in your dataset, you can select that column to be the primary key, and users that already exist with a given email in the database are updated instead of being added again.
Additionally, you can use the following options:
| Option | Description | Interacts with |
|---|---|---|
| Remove missing users | When this option is ON, non-system users not in the source data are removed | None |
| Deactivate missing users | When this option is ON, all users which are not present in the source data are set to inactive (AccessUserActive = false) | None |
| Generate passwords for users | Generates a password for imported users, provided that the user is new (not already in the Dynamicweb database) and the source data contains either no password or a NULL or empty string in the password column. If the user is already in the database and has NULL or an empty string as a password, a password will also be generated. | None |
| Encrypt passwords | Encrypts passwords present in the source data, and passwords generated for new users using the Generate passwords for users option | If Generate passwords for users is ON, they are also encrypted |
| Remove users group membership, if group is not in import | If Remove missing users is ON, and you import to a user group, users which are not in that user group will be removed | Only used in conjunction with Remove missing users – otherwise ignored |
| Remove missing groups | Removes user groups not present in the source data | None |
| Remove missing impersonation rows | Removes impersonation rows not present in the source data | None |
| Remove missing addresses | Removes addresses not present in the source data | None |
| Discard duplicate key rows | When ON, duplicate rows are ignored | None |
| Use email for username | When this option is ON, newly imported users will use the value from AccessUserEmail as the AccessUserUserName. Existing users will not have their user names updated, and will be updated only if the username field is empty | None |
| Use email for username | Assigns email addresses as usernames for all imported users | None |
| Destination group | Select a group to import users into | When Replace current group membership is checked, the the imported users are forced to only belong to this group |
| Replace current group membership | Forces the imported users to only belong to the selected user group | Refers to the selected Destination group |
| Remove missing rows after import | Removes rows from the destination and relation tables. This option takes precedence | |
| Remove missing rows after import in the destination tables only | Removes rows from the destination table, but not the related tables | Remove missing rows after import takes precedence over this setting |
| Persist successful rows and skip failing rows | Checking this box allows the activity to do partial imports by skipping problematic records and keeping the successful ones | None |
If you generate (and encrypt) passwords for new users on import, you can use the email configuration fields to set up automatic notifications to newly created users. To do so:
- Provide an email subject
- Enter sender email
- Select or create an email template to use - you can use both Razor and html based templates.
It is also possible to select index repositories to update on every import. Please notice that updating index repositories may cause slower performance temporarily.
Automatic table sorting
When a job using the User provider as either source or destination is run, the table imports are automatically executed in the following order:
- AccessUserGroup
- AccessUser
- AccessUserAddress
- AccessUserSecondaryRelation
Any manually defined order different to this sequence will be overwritten to maintain proper data relations.