What is a ‘service user’?

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’.

 

NOTE: 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.

 

Why is this recommended?

Using a dedicated service user instead of the credentials of an existing user can have the following benefits:

 

• It helps ensure team members don’t need to share their personal credentials.
• Allows you to be more intentional with access permissions for the integration, which might differ to the permissions of your users.
• Can make activities like access management easier, as revoking access for a team member won’t impact the integration (and vice versa).

 

NOTE: 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.

 

Recommendations when setting up Service Users

Tip 1: Talk to your IT Security team first

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.

 

Tip 2: Use a descriptive name for the user

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.

 

Tip 3: Use an email address that can be accessed for password resets when needed

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.

 

How many service users do I need?

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.

 

Approach 1: A single service user in the DMS for all Felix projects

 

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:

1. In the DMS, you will need to make sure that the service user is given access / permission to the new DMS project that you want Felix to connect to.
2. For each project in Felix that you want to connect to the DMS, enable the DMS integration and use the credentials of the service user.

 

TIP: 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.

IMPORTANT: 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.

Approach 2: One user in DMS for each project

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:

1. Create a new service user in the DMS for the project, and ensure it has permission to access the relevant project.
2. Connect the project in Felix to the DMS and use the credentials of the newly created service user.

 

TIP: 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.

 

 

Approach 3: A hybrid approach

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:

 

1. Determine if a new service user is needed, or if an existing service user can be used.
2. (If needed) create the new user in the DMS.
3. In the DMS, make sure that the service user is given access / permission to the new DMS project that you want Felix to connect to.
4. For the new project in Felix that you want to connect to the DMS, enable the DMS integration and use the credentials of the service user.

 

TIP: 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.