Flex

Integration with Flex (https://www.flexapplications.se/hr-system/) is a one-way-synchronization that updates employee data in Winningtemp from Flex.

Prerequisites

First, an integration user needs to be set up in Flex, instructions for how to do so will be supplied on project start, or can be requested from Flex themselves.

In addition, we'll need the base URL for your instance of Flex, which looks something like this:
https://COMPANY.flexhosting.se

Where COMPANY would be replaced with your domain.

Finally, we need the ID of your Flex instance, as well as the IDs for all companies within that instance that should be included in the integration. Please note that including more than one company ID falls outside the scope of our standard integration, and will require some modification of the solution on our end.

See a full specification of the above requirements:

• Base URL
• Username
• Password
• Instance ID
• Company ID(s)

Syncing User Data

By default, the following values can be synced for each user, Flex field naming in parentheses ():

• External ID (Id) - An external ID must be a unique value that points to this user, now and in the future. It needs to be something that never, or rarely changes. It is primarily this value that the integration uses to identify whether a user exists in the system. If they should be created or removed. ​
• Username/Email (EmailWork) - Needs to be unique for each user. It is this value that the user enters to login to the system. As a rule, we recommend that the username and email should use the same value. ​
• First Name (FirstName) - Primarily used to navigate the user directory during administration. The welcome message for a user is based on this value. ​
• Last Name (LastName) - Primarily used to navigate the user directory during administration. The welcome message for a user is based on this value. ​
• Gender - Used to present results related to gender identity.​ Flex sends values 1, 2 and _, referring to Male, Female and None respectively.
• Birthday (DateOfBirth) - Used to present results based on age interval. A user's birthday can also be highlighted in the activity flow and calendar view. ​
• Manager (ImmediateManagerEmployeeId) - Used to place another user as the manager for the group this user belongs to.
• Exclude from Surveys (EmploymentType) - Used to exclude users from surveys if the have the the Employment Type "External Personnel".

Any user field in Flex could in theory be sent to WT. These are configured for prior to implementation in collaboration with a technical consultant. Please note that adding custom fields may affect the project lead time.

For more information regarding values available in WT, and what they are used for, please refer to our Syncable Values .

Syncing Organizational Data

Including organizational data is significantly more complex than simply user data. To be able to generate and maintain a group structure in Winningtemp based on organizational data, we need the following:

• Group Name - Simply the name of the group as shown in Winningtemp
• Group External ID - A static identifier that points to a group in the system, has to be unique
• Parent Group External ID - The static identifier that points to the group above this one in the hierarchy

For more information on how Winningtemp builds groups for the integration, please refer to our article on Syncable Values.

The key here is the relationship from one group to another, as represented by the "Parent Group External ID". This relationship doesn't exist within Flex, but we can sometimes fake it using the following setup:

By having two or more organizational fields on all your users in Flex, we could simulate a hierarchy by creating groups based on the values provided in each field, and deciding the depth of a branch based on which field the value is taken from. For example, imagine we had three organizational fields on a user:

1. Office-field: "Stockholm"
2. Department-field: "Finance"
3. Team-field: "Payable"

We'd create a group called Stockholm at the top of the hierarchy (right below the organization-level). Then create a group called Finance as a child of Stockholm, and then a group called Payable as a child of Finance.

If another user is also part of the Stockholm office, finance department, but belongs to the "Receivable" team instead. We'd see that Stockholm and Finance was already created, and so we'd add Receivable as a child of Finance, right next to Payable.

The group affiliation of a specific user would be based on the "lowest" of these fields. With the value "Payable" in the Team-field, we'd place the user in Payable. If Team was empty, we'd place them under Finance. If Department was empty, we'd place them under Stockholm.

In theory, we could generate any depth of hierarchy this way, but there's a fairly significant limitation. Specifically, as each group needs to be unique, you can't have more than one department with the value Finance, even if it's in a different office. We could potentially get around this limitation by generating IDs based on previous fields too, i.e "Stockholm Finance Payable", but this results in a flimy, error-prone solution. Not to mention hard to troubleshoot.