Syncable Values

There are a number of possible values that can be synced via the integration.
As a general rule, with a few notable exceptions, if there’s a field or value for it in
Winningtemp, it can be synced via the integration.

It’s worth reiterating that these are values that are possible to sync.
There are only a few values that are actually mandatory for the
integration to be able to create the object, and these will be marked accordingly in the
list below.
Anything else can be sent as empty, or simply not be synced/included.

These values are as follows, divided by type of object:

Users (Mandatory)
- (User) External ID - Mandatory Value - As mentioned in the section of the same
  name above, an external ID has to be a unique value that points to this user,
  now and in the future. It needs to be something that never or rarely changes.
  Company Email, or any other value generated from an employee’s name, is
  generally not recommended for this very reason. A “neutral” value, such as an
  Employee ID, or equivalent, is usually a better fit.
- First Name - Mandatory Value - This is used to identify the user administratively. It’s also used in cohesion with last name while welcoming the user when they log in. It can be seen by the user in their profile.
- Last name - Mandatory Value - This is used to identify the user administratively. It’s also used in cohesion with first name while
  welcoming users when they log in. Can be seen by the user in their profile.
- Username - Mandatory Value - Has to be unique. This is used by the user when
  logging into the system. Doesn’t have to be the user’s company email, but if
  that value is already supplied for the Email column, it is generally
  recommended to keep it as the username as well.
- Email - Optional Value - While technically optional, it is highly recommended
  that users be supplied with an email to get the most out of the service. Users
  lacking an email can’t reset their own password and have to rely on logging
  into the system to respond to surveys. If an email is provided, it is also
  recommended as the username.
- Birthday - Optional Value - Default format: yyyy-MM-dd, but most formats
  supported if necessary. Birthday is used to calculate age, which is used
  to categorise users by their appropriate Age Brackets. Age Brackets is a dynamic segment generated by the system, which allows administrators to filter results based on ranges of age.
- Employed Since - Optional Value - Default format: yyyy-MM-dd, but most
  formats supported if necessary. Employed Since is used to calculate
  Employment Interval. Employment Interval is a dynamic segment generated by
  the system, which allows administrators to filter results based on ranges of
  employment duration. Can also be used to set up our automatic onboarding
  surveys. If a user is created/updated with an Employed Since date that is in the
  future, that user will be deactivated in the system until that date.
- Employed Until - Optional Value - Default format: yyyy-MM-dd, but most formats
  supported if necessary. Employed Since is used to calculate Employee
  Turnover, where administrators can analyse results based on how
  long the employee has left in the organization. This is most often relevant from
  point of view higher in the hierarchy, as there are seldom enough users leaving
  within a specific timeframe within a team. Can also be used to set up our
  automatic offboarding surveys. If a user is created/updated with an Employed
  Until date that is in the past, that user will be deactivated in the system.
- Gender - Optional Value - Default format: M/Male/Man = Male,
  K/Female/Kvinna = Female, = Prefer not to answer, where usually refers to
  any value not covered by the defaults. Can be expanded to cover specific
  values if required. Gender is used to determine Gender Identity. Gender Identity
  is a dynamic segment generated by the system, which allows administrators to
  filter results based on on gender identity.
- Team Member - Optional Value - Expected value here is a Team External ID.
  This should be the ID of the team that this user is a member of in
  Winningtemp.
- Manager - Optional Value - There are three mutually exclusive ways to use
  this value, but they all refer to setting the Manager role for a team in the
  system. Possible values are:
  - Team External ID - Provide the external ID for the team that this user
    should be the manager of.
  - User External ID - Provide the external ID for a user. The logic here is then
    that whoever matches the provided ID should be set as admin for the team this user belongs to, according to the value provided for Group Member.
  - Third option sees this value transferred to the Teams section instead.
    (Read on for details)
- Segment - Optional Value - Should contain a Segment External ID. This can
  relate to pre-existing segment either generated automatically (as described later in this article) or manually directly in Winningtemp. But for the sake of simplicity, we often set
  up the logic that a segment without a matching value in WT will simply make the
  integration create a new segment with the value provided here as the ID. If any
  other users have the same Id, they would then be added to this new segment.
- Status - Optional Value - Default format: Active/True/1 = Active,
  Inactive/False/0 = Inactive. Can be adjusted for other formats if required.
  Status, simply put, determines the Status of the user, which fundamentally affects their ability to utilise the service, as defined in the related article
  marked above as recommended reading. While syncing this value is optional,
  if you choose to do so, it will mean that all users must have a value provided
  here. It can’t be empty unless an empty string is defined as one of
  the possible values.
Teams (Optional)
- (Team) External ID - Mandatory Value - As mentioned in the section of the
  same name above, an external ID has to be a unique value that points to this
  team, now and in the future. It needs to be something that never, or rarely
  changes. The name of a department or team, or any other value generated
  from a name or location, is generally not recommended for this very reason. A
  “neutral” value, such as Cost Center, or equivalent, is usually a better fit.
- Team Name - Mandatory Value - The group name is what’s visible in the
  system. The administrator uses it to navigate the structure when analysing
  results. And, it’s what a user sees in their overview.
  - Parent Team ID - Optional Value - While not strictly mandatory, this value is
    what determines the hierarchy of the organisational structure. An empty value here will
    simply make all teams sit on the same level, right below the organisation as a
    whole. To resolve this, the value provided here needs to be the External ID of
    the team that lies above this one in the structure. Based on that simple
    relationship alone, we can create a hierarchy of any depth.
  - Manager - Optional Value - As mentioned in the logic for setting managers via the Users section. If we move this value to the Teams section instead, assuming a User External ID, we can have the following logic:
    The user that matches this external Id should be manager for this team.
Segments (Optional)
- (Segment) External ID - Mandatory Value - As mentioned in the section of the
  same name above, an external ID has to be a unique value that points to this
  segment, now and in the future. It needs to be something that never or rarely
  changes. As segments are generally a bit more static than users or groups, you
  don’t necessarily have to be as strict for segments. Often, segment name is
  simply used for the ID as well.
- Segment Name - The segment name is what’s visible in the system. It’s used by
  the administrator to navigate to the segment when analysing results.