Hi. Could you flip your approach and use an automatic group to put someone in based upon the completion of one of the courses perhaps?

@LSgouros 

• how are you managing your users by hand or by integration?
  • could you have your HRIS folks send along a flag that they calculate on their end? You mark them as a new employee for the first X days with a Y for example.
• it sounds like you would benefit from using learning plans that are more “object permanent”. To do that we generate all new learning plans as we move along as content technically expires and we add new content. Where that may sound burdensome, the approach is sound and supports the audit cleanly.

Feel free to DM me if you would like.

I don’t know what you mean, Jeanette.  Would putting them in a group somehow take them out of the old group?

@dklinger Do you then have to create new enrollment rules or update the existing enrollment rules with the new LP names?

@dklinger - forgot to answer your question.  We do daily uploads from two payroll systems to bring learners into Docebo.  It’s fairly new for us and we are still working out minor glitches (like we probably should have chosen something other than emails as the username, but that’s a whole different topic!)

What is “object permanent?”

@LSgouros  Hi, Lynn

You have several things going on here...all of which I deal with myself every day no easy solutions.

1. Learning Plans … you can’t add new courses to an existing learning plan without old people getting enrolled, too. So either you have to get those persons who are “complete” out of the learning plan (before adding a new course), or you have to build a new learning plan with the new courses and move the incomplete enrollments over from the old learning plans.
2. Automatic Groups … you can build automatic groups with additional fields. Maybe you could have a field that says “new hire”, and then periodically update that field to remove the new hire flag. I’d recommend that you monitor the group the day after updating the fields to confirm that the group updated correctly.
   1. Unfortunately, removing someone from a group does NOT manage their enrollments into the LP. So… you would need to still find a way to manage the LP (see #1 above).

In my situation, I’ve used additional fields to manage their job title, not their longevity. I have a page in the menu that contains a page with only new hire courses and this is their home page. Their post-new hire courses are available on a separate page; we train them during NH to use the second page for their upskilling courses.

Yes we update or create new enrollment rules.

• if you can send along a single additional field to act as a flag for a new employee - it may help you. Let payroll calculate for you if the person has been onboard for X days….if it is true - the flag should be a Y. If it is false it should anything else.
• Object permanent meaning once a learning plan goes completed, you dont want the LPs to get marked as incomplete because you changed the status of something from within (in this case a course).

No, but if you plan your menus correctly and catalogues even, their experience can change.

With groups you only have 4 potential criteria:

1. Enrollment status
2. Branch
3. User fields
4. User additional fields

Most likely you’ll want use one of the “user additional fields” to manipulate a group’s membership for this.

You essentially will need to trigger enrollment/disenrollment off of the changing of one of these user additional fields, and that could happen from a feed from your HR system or from an outside process that works with the value of the user additional field.

For my suggested solution you’ll need a date type field for the “user additional field”, populated with the hire date from the HR system. Then create a new hire group with automatic membership and set the conditions to give you a 30 (or 90) day span of time using the “is in the range” operator and some arbitrary dates (perhaps from today through 30 days from today).  The dates you put in are going to be changed each day through the API.

For this thought experiment, set the new date field for just your own account to something within the 30 day window and verify that you were automatically added to the new hire group.  Cruise over to the API Browser at YOUR URL/api-browser, select, “manage” from the left-hand menu, and jump down to the section “audiences”.

After authenticating, choose “Get All Audiences” from the menu and put in the name of your group as the search criteria.  You should see your group with information something like this.  Jot down the UUID field near the top, and notice the FROM and TO fields about 2/3 of the way down in the rules section:

{
  "data": {
    "items": {
      {
        "name": "test with date range",
        "description": "",
        "labels": r],
        "uuid": "xxxxxxxx-0430-f9",
        "type": "automatic",
        "updated_by": {
          "idst": 12345,
          "name": "First Last",
          "firstname": "First",
          "lastname": "Last",
          "email": "first.last@somedomain.com",
          "userid": "first.last@somedomain.com",
          "avatar": null
        },
        "updated_at": "2024-04-25 16:41:38",
        "created_by": {
          "idst": 12345,
          "name": "First Last",
          "firstname": "First",
          "lastname": "Last",
          "email": "first.last@somedomain.com",
          "userid": "first.last@somedomain.com",
          "avatar": null
        },
        "exclude_deactivated_users": false,
        "ruleset": {
          "status": "READY",
          "operator": "AND",
          "sets": a
            {
              "id": "xxxxxxx-6aa2-fc",
              "rules_operator": "AND",
              "rules": :
                {
                  "id": "xxxxxxx-005c-2a",
                  "type": "UserAdditionalField",
                  "payload": {
                    "field": "32",
                    "predicate": {
                      "to": "2024-05-25",
                      "from": "2024-04-25",
                      "operator": "between"
                    }
                  }
                }
              ]
            }
          ]
        }
      }
    ],
    "count": 1,
    "has_more_data": false,
    "cursor": null,
    "current_page": 1,
    "current_page_size": 50,
    "total_page_count": 1,
    "total_count": 1,
    "sort":  
      {
        "sort_attr": "name",
        "sort_dir": "asc"
      }
    ]
  },
  "version": "1.0.0",
  "_links": "]
}

Now scroll down to Update An Audience. In the top box, put the following. Note that most of this is a copy/paste from the result above.

{
  "name": "test with date range",
 "ruleset": {
          "status": "READY",
          "operator": "AND",
          "sets": a
            {
              "id": "xxxxxxx-6aa2-fc",
              "rules_operator": "AND",
              "rules": :
                {
                  "id": "xxxxxxx-005c-2a",
                  "type": "UserAdditionalField",
                  "payload": {
                    "field": "32",
                    "predicate": {
                      "to": "2024-05-25",   << --CHANGE THIS DATE
                      "from": "2024-04-25",   << --CHANGE THIS DATE
                      "operator": "between"
                    }
                  }
                }
              ]
            }
          ]
        }
}

In the bottom box put in the UUID (xxxxxxxx-0430-f9) in my example.  Obviously also take out the “<<--CHANGE THIS DATE” as well.  You should be able to change these dates so that your account no longer fits the group membership criteria.

Now that you’ve been able to change the dates through the API Browser, you can apply this same idea to whatever automation tool you’re using (Docebo Connect/Workato, Make, Tray.io, Boomi, etc.). Once a day you would update the TO and FROM dates.  This saves you a LOT of cycles over looping over every user account individually.

You’ll use a PUT call to:
https://YOUR-URL/audiences/v1/audience/YOUR-UUID

and send your JSON (similar to mine) to that endpoint.

Enjoy!