Users can be created in Passport either manually or through a bulk upload file. Manual creation is suited for low-turnover organizations, while bulk uploads are ideal for managing large user volumes systematically. Bulk upload files must adhere to specific formatting rules, including the use of separators (| for intra-field and , for inter-field) and strict header order. Updates overwrite all user privileges. Fields include user details, job codes, and access specifications for facilities, units, or views. Save the file as .csv
and upload via SFTP or the Integration Tab under "User Data."
Overview of User add/edits:
1. Manually within the user interface - Ideal for low turnover and manual management. You can find instructions for this process here: How Do I Add A User?
2. Uploading a User File - Ideal for clients to automatically upload large volumes of users, and systematically control access.
Some items to keep in mind:
1. The vertical bar (|) is defined as the intra-field separator.
2. The comma (,) is the inter-field separator.
3. A user definition is not ‘incremental’. That is, the record, as stated, represents the total set of privileges for a given user. An update will replace all capabilities with the specified ones.
All headers need to remain in exact order and spelling.
Column Name | Notes |
Prefix | Optional: Name prefix (Ex. Mr. Ms. Etc) |
First Name | Required: First Name of User (Ex. Steven) |
Middle Name | Optional: Middle Name of User (Ex. John) |
Last Name | Required: Last Name of User (Ex. Smith) |
Login Name | Required: Unique Email Address (Ex. SJSmith@client.com). Must be an email address |
Email Address | Required: Unique Email Address (Ex. SJSmith@client.com) |
Password |
Optional: If the password field is set (has a value), then that value will be used for that user's login. If not specified, the system will generate an internal password.
*If the client is on SSO, leave this field blank. |
PW Expires |
Optional: PW Expires sets the number of days until the user must reset the password. If 0, the password will not expire. This expiration policy is set whether or not system or user-specified password is set. Must be even numeral to establish a unit of days.
*If the client is on SSO, leave this field blank. |
Delete user? | Required: This field indicates whether the user should be deleted entirely. Acceptable input is either 1 or 0, with 1 being delete, and 0 being to not delete |
Email Services |
Optional: This field indicates any email services that need to be generated to the user based on this file. Two values are allowed if you want an email on both user account addition and update. In that example, you'd specify 2 space 3. |
Other Services |
Optional: This field is reserved for future expansion and contents are ignored at this time. |
Jobcode |
Required: This references a job code table that will be statically hosted in the client's SFTP folder "job codes". See the article below for specifications on how to build the job codes definition table: How To Create Job Code User Definitions to Use with User Bulk Upload Once the definition table is built and sitting in the proper folder on the SFTP Site, this field on the user file will reference that job code table when processing. Whatever number or naming system is being used in the table should be populated here for each user. This job codes file defines how DEEP a user can drill down and access the data. |
Node Type | Optional: This column and the Node Integration Column will only be used if you are using the Hierarchy Dashboard and have already established a Hierarchy within the system. You would then be able to reference a pre-defined Node Type and Integration ID as a shorthand for indicating that a user should have access to this top most node as well as all nodes that it parents. The Type and Integration ID of the node must match a single pre-defined Node that has already been designated. Acceptable Node Types are below 1. Network 2. Facility 3. Named If you use the node columns on this file, you would not use the View, Facility, or Unit columns. For more information on how to build a hierarchy within your Passport system, you can refer to: Create a Hierarchy File |
Node Integration ID | Optional: This column and the Node Type Column will only be used if you are using the Hierarchy Dashboard and have already established a Hierarchy within the system. You would then be able to reference a pre-defined Node Type and Integration ID as a shorthand for indicating that a user should have access to this topmost node as well as all nodes that it parents. The Type and Integration ID of the node must match a single pre-defined Node that has already been designated. For example, the Node Integration ID for a Facility Node Type would be the Facility ID. A Named Node Type would be whatever unique ID was established for the named node. A Network Node Type would use the Organization ID that is unique to each client. (Found under Integration > Integration Mappings) If you use the node columns on this file, you will not use the View, Facility, or Unit columns |
View |
Optional: If View is specified, the following two columns of Facility and Unit as well as the previous columns for Hierarchy are required to be blank. If View is NOT needed, leave it blank, and move to the next column for data. The last three fields work in combination to define the visibility range of each user, or "where can they look". This is separate from the job code column which references "how deep can they look into". By using * (asterisk symbol) - a view based on the permissions defined below will automatically be created for the new user.
There is an additional expandable format if your organization needs a more flexible combination of specifying only certain units across multiple facilities. If you need these most advanced and flexible options, please contact the Client Care Team to have a more in-depth consultation of your needs. |
Facility |
Optional: When a pre-defined "VIEW" or "HIERARCHY" cannot handle the access for this user, the client can explicitly list one or more units they should be able to access. If VIEW or HIERARCHY is being used, this column should NOT be populated and will cause a failure as the View already defines facility specifications. This is only necessary to populate if you need to restrict access not to an entire VIEW or entire FACILITY, but need to narrow to only some units within a previously specified facility.
There is an additional expandable format if your organization needs a more flexible combination of specifying only certain units across multiple facilities. If you need these most advanced and flexible options, please contact the Client Care team to have a more in detail consultation of your needs. |
Unit |
Optional: When a pre-defined "VIEW" or "HIERARCHY" cannot handle the access for this user, the client can explicitly list one or more units they should be able to access. If VIEW or HIERARCHY is being used, this column should NOT be populated and will cause a failure as the View already defines facility specifications. This is only necessary to populate if you need to restrict access not to an entire VIEW or entire FACILITY, but need to narrow to only some units within a previously specified facility. There is an additional expandable format if your organization needs a more flexible combination of specifying only certain units across multiple facilities. If you need these most advanced and flexible options, please contact the client care team to have a more in-depth consultation of your needs. |
*This file is meant to be used in conjunction with a static job codes definition template. Instructions are available: How To Create Job Code User Definitions to Use with User Bulk Upload
Be sure to always save this file as .csv and upload directly into the user_update in your SFTP site or upload to the File Submission section under the Integration Tab and select file type as User Data.
Attached below is a sample Short Form User File.
If you have any questions, please reach out to the client care team at support@providertrust.com or 615-938-7878 ex 1.