A ‘service user’ is a term we use to describe a user account that is created for the sole purpose of allowing an integration to access and interact with an external system (such as a DMS).
Some of the systems that Felix integrates with have APIs that that are tied to user accounts in that system. This means that when configuring an integration in Felix, you will need to enter the credentials (i.e., username and password) of that user account into Felix so that our integration can connect to the other system, and act “on behalf of” that user.
Rather than entering the credentials of an existing team member into the integration, it is generally considered best practice to create a separate user account in the other system for this purpose – which we call a ‘service user’.
There may be additional costs associated with creating new users in the DMS. If you are unsure, you should contact the DMS provider to confirm before creating users.
Using a dedicated service user instead of the credentials of an existing user can have the following benefits:
Not all systems and integrations need service users!
This practice is useful for integrations like the InEight Document, Aconex and Asite integrations, but might not be necessary for integrations like eftsure where the eftsure team will create an API user for you to use.
First and foremost, we recommend discussing this with your IT Security team, as they might already have guidelines and procedures for you to refer to. Those policies and procedures should generally take priority over our recommendations.
Ensure the user’s name in the other system (e.g., the DMS) clearly identifies that is used for Felix. Use what makes sense for you and your team, as a starting suggestion you might consider “Felix Integration”.
This will help you identify the purpose of the user during security reviews.
Additionally, this can be helpful when reviewing logs in the other system to see who performed specific actions, as they could say something like “File downloaded by ‘Felix Integration’”. This varies from system to system, and you might need to consult the support materials for the other system to learn more about which actions are logged and how they are displayed.
A service user account is intended to primarily be used by the integration and not a person, but sometimes the credentials for those users need to be reset.
A common method for resetting the password via the email address on the account. For this reason, we recommend ensuring the email address used for Service User accounts is a real email address that is monitored.
We recommend discussing this with your IT team, as they might want this to go to a specific shared email inbox that they can monitor and act on.
Deciding how many service users to create is balance between IT security policies, administrative maintenance, and potentially costs.
There are trade-offs in the amount of effort required to administer the different options, so the decision on how to manage this will likely be based on how your organisation works.
To help you think through some of the possibilities, we’ve described a few different options below, but the choice is up to you and your team.
With this approach, there is a single user created in the DMS system for Felix’s integration to use to interact with all the projects in the DMS. This option is useful if you wish to minimise how many service users are created in the DMS.
One service user in the DMS ó Multiple projects in Felix.
When connecting a Felix project to the DMS, the workflow might look like this:
Optional: when a project is finished, and the integration is no longer needed, you can “cleanup” the access:
1. In Felix, disable the integration for the project.
2. In the DMS, remove permissions on the Service User for the completed project. Be sure to leave the permissions intact for ongoing projects for the integration use.
Things to be aware of: As this service user has access to multiple projects in the DMS, and is tied to multiple projects in Felix, changes to this account in the DMS can have a wider impact than you might expect. For example, if the service user’s credentials are updated in the DMS, then typically the DMS integration will stop working. You will need to update the configuration for all connected Felix projects with the new service user credentials to restore the integrations.
With this approach, there is a new service user created in the DMS system for each Felix project that you want to connect to. If you have ten projects in Felix that you wanted to connect, then you would have ten service users in the DMS – one per project.
This option minimises the impact of an individual service user’s credentials being compromised (as each service user would only have access to a single DMS project instead of multiple), but this comes at the cost of more administrative overhead.
One service user in the DMS ó One project in Felix
When connecting a Felix project to the DMS, the setup workflow might look like this:
Optional: when a project is finished, and the integration is no longer needed, you can “cleanup” the access:
1. In Felix, disable the integration for the project.
2. In the DMS, remove permissions on the Service User for the completed project. Be sure to leave the permissions intact for ongoing projects for the integration use.
If necessary, you can combine aspects of Approach 1 and Approach 2 to “right size” the number of service users. This would involve creating multiple service users as needed, with each having access to one or more DMS projects based on business units, business rules or compliance requirements.
An example might be if you had different service users based on business units – an Australian team might choose to manage their own service user, whilst a team in the United Kingdom might choose to manage their own service users.
If you chose this path, we strongly recommend creating documentation for your teams on how to manage this going forward, as it can be complicated to setup and review in future.
When connecting a Felix project to the DMS, the workflow might look like this:
Optional: when a project is finished, and the integration is no longer needed, you can “cleanup” the access:
1. In Felix, disable the integration for the project.
2. In the DMS, remove permissions on the Service User for the completed project. Be sure to leave the permissions intact for ongoing projects for the integration use.
