Workday Accounts Connector: Name and Description not updating

[gmilunich (Geoff Milunich)]

I am trying to pull in Entitlements from a Workday Accounts Direct Connector. THe connector has been configured with OAuth 2.0 and the permissions provided. This has been verified in another environment which is receiving the fields.

The Schema is configured as follows, and I added the descriptionAttribute based on another topic here mentioning it might be needed. I see that the ID Field is listed for both identityAttribute and displayAttribute.

{
    "nativeObjectType": "SecurityGroup",
    "identityAttribute": "ID",
    "displayAttribute": "ID",
    "hierarchyAttribute": null,
    "includePermissions": false,
    "features": [],
    "configuration": {
        "descriptionAttribute": "COMMENT"
    },
    "attributes": [
        {
            "name": "ID",
            "type": "STRING",
            "schema": null,
            "description": "The internal id for this group.",
            "isMulti": false,
            "isEntitlement": false,
            "isGroup": false
        },
        {
            "name": "COMMENT",
            "type": "STRING",
            "schema": null,
            "description": "The Description/Comment of the Group.",
            "isMulti": false,
            "isEntitlement": false,
            "isGroup": false
        },
        {
            "name": "DESCRIPTOR",
            "type": "STRING",
            "schema": null,
            "description": "The Name of the Group.",
            "isMulti": false,
            "isEntitlement": false,
            "isGroup": false
        }
    ],
    "name": "group"
}

What is odd is that I can see the Comment and Descriptor filled out for the entitlements when I look at them, however, for the majority of the entitlements, the ID is still set for the name, and the Description field is still blank. I have aggregated entitlements and accounts since.

Is there a step or configuration I am missing?

[gmilunich (Geoff Milunich)]

Just to update this for those that might find this later. I was able to get this working using the API.

First, a little more on the background. The connector was created and the permissions were set up for OAuth 2.0 in the production environment, but in sandbox, it was initially configured with basic auth and then changed to OAuth 2.0 after it was realized we needed it for the name and description. This configuration was tested and correct, based on the COMMENT and DESCRIPTOR values showing in the Metadata of the entitlement (but not in the name and description as expected)

So based on the above link, I updated the schema using the suggested value:

---

From Post #5 by @dinesh_mishra in the link above

---

Update for this end-point: /sources/{sourceId}/schemas/{schemaId}

Method: PATCH
Headers: Content-Type: application/json-patch+json
Payload:

[
  {    
    "op": "add",
    "path": "/configuration/descriptionAttribute",
     "value": "COMMENT"
   }
]

---

Using this and doing the entitlement aggregation allowed some of the descriptions to be updated with the values in the COMMENT field (Which was confirmed to be the Description field in our environment. ymmv) It did not pull in all of them however.

The next thing I looked at is if there was a way to do an Unoptimized Entitlement Aggregation, like there is with the Account Aggregation. According to the Entitlement Aggregation documentation for the Beta API there is not a way to do that. I ran the Entitlement Aggregation anyways hoping that calling it from the API would be different than the UI> It was not, and there were still missing descriptions.

For fun, I decided to add the “disableOptimization=true” to the Entitlement Aggregation API call in the same manner that it is added to the Account aggregation and run it against the Sandbox instance. I figured it couldn’t hurt in sandbox. Well, it took a bit longer to run than the previous one, but low-and-behold, it WORKED! All the descriptions showed up as expected, and even some of the names were updated, however not all.

NOTE: Using disableOptimization with Entitlement Aggregation is Undocumented. Use it at your own risk! It’s functionality may stop working (or even may be a placebo effect here)

The next step was to try and get the names to work. I decided to first try and follow the example above for the description, so I added the following to my schema:

[
  {    
    "op": "add",
    "path": "/configuration/displayAttribute",
     "value": "DESCRIPTOR"
   }
]

This did not seem to change anything, but my testing included other changes at the same time that did have some effect, so I am leaving this here since it was part of the process, and it is still in my working solution.

Next, I got looking at the Schema itself to see if there was anything I was missing or that looked like it might work. I saw that on the base schema, the “identityAttribute” and the “displayAttribute” (Not the same as above) were both set to “ID”. So for testing, I decided to change the “displayAttribute” to “DESCRIPTOR” using the following:

[
   {    
    "op": "replace",
    "path": "/displayAttribute",
     "value": "DESCRIPTOR"
   }
]

I then ran the unoptimized aggregation. After doing both of these, the Display Name attribute was updated and the source entitlements in Sandbox were correct as I would expect.

NOTE: I did try running the entitlement aggregation from the UI before each API run just to check, and they had limited, partial success at best.

NOTE: For testing, I changed this value back to “ID” thinking I might have bypassed some backend processing. When I did, some of the Entitlements had hte Display Name field revert back to the “ID” field, even though they had the “DESCRIPTOR” field populated. So if there is backend processing to choose “DESCRIPTOR” over “ID” if available, then it is not working consistently.

So with that working, I decided to try it in Production. I used the following patch update for the schema:

[
  {    
    "op": "add",
    "path": "/configuration/descriptionAttribute",
     "value": "COMMENT"
   },
   {    
    "op": "add",
    "path": "/configuration/displayAttribute",
     "value": "DESCRIPTOR"
   },
   {    
    "op": "replace",
    "path": "/displayAttribute",
     "value": "DESCRIPTOR"
   }
]

Once it was patched and I verified it, I ran the Unoptimized Entitlement Aggregation. After that completed, I checked the results and the Entitlements has the proper names and descriptions as expected.

So this issue is SOLVED for us. Because of the undocumented features in the API calls, you will want to do your own testing if you run into this.