Jeremy Davis
Sitecore, C# and web development
Recently I wrote a bit about one way of showing status of Content Hub State Flows in entity listings. Having worked on that a while ago, I found myself needing to deploy theses changes to production recently - and that brought up a couple of fun problems with using State Flows. Here's some info on what I saw, and how I worked around it:
url copied!
The work I'd been doing created a collection of custom entities, and applied State Flows to them to enable workflow. Two of the things I set up as part of the state flow were "what security groups are required to transition out of each state" (i.e. only approvers can click the "approve" button when the entity is in the "awaiting approval" state) and that changes of state updated a custom field which stored a project-specific workflow state.
The settings on each State looked something like:
This was all working fine on my non-prod Content Hub instance. But when I came to generate an export package and import that into the Production instance for the first time, the two features above stopped working. The role changes and the custom field values were no longer applied when the state changed. Looking at the same State after the deployment I saw:
The "Update assignees" and "Update
url copied!
My initial thought on what had happened was that these two settings rely on relations to other bits of data in the Content Hub instance. The "Update assignees" fields relate to user groups and the custom field setting relies on the data type of the field - which was a Taxonomy in this case. So perhaps there was an import ordering problem here, and these specific entities hadn't been created at the point the State Flow was being set up?
To test this, I tried re-importing the state flow data. You could probably re-import the entire package here, but in my case it was fairly big (and hence slow) so I chose to copy it and edit the contents. I removed everything bar the set of States which had been incorrectly imported. In theory all the things they depended on would exist now, so the importer should just fix them...
Well I was half right. After this second import succeeded, the view had changed to:
The "Update assignees" fields are correct again. The import does appear to have correctly fixed that relationship now that the relevant user groups exist in the production instance. But the custom field for status isn't fixed. It's got the right verb now (it's gone from the default of "Keep" to the correct "Overwrite") but it doesn't have the correct value to write selected...
url copied!
This sort-of makes sense in light of some other challenges I've had migrating Content Hub stuff. The individual values in a Taxonomy are entities, and hence have a numeric Entity ID. I know from past experience that Content Hub does not copy these values between systems when you move things. It appears that these ideas are database-level auto-increment IDs, and the processes for moving your data don't (or can't) import values for them.
This had come up before when migrating Script code which had to set specific states for taxonomy-based fields. To use the API to write a value you have to supply the numeric ID of the Taxonomy entry. But this is never the same between Content Hub instances, even if you moved the Taxonomy with a package.
So tediously the fix here seems to be to manually set the right values again. That will give the State the correct ID for the Taxonomy Entry it's setting.
url copied!
If you're used to the ease of deploying schema and content in Sitecore's DXP then Content Hub packages are going to be something of a pain for you. But it looks like you can fix some of these issues if you're careful about the order you move things in, or you're prepared to run imports more than once.
But sometimes, maybe you just have to manually set stuff a second time...
↑ Back to top
