It seems publishing a blueprint with a new specifics member on Demo / OOTB 9.3 content generates an error "There is already a business object with the name Specifics.
I don't know yet of a fix for this.
Update - changing the name of the group leader and appending 'Leader' to the alias, plural and internal names made the issue go away. Seems like a specific in the demo content has a conflicting name.
I ran into this issue on a customer site last week and it appears that the renaming of the new group member isn't happening correctly. I fixed this in the definition editor manually and then logged a job with support.
This also seems to be happening for fields and records like OOTB teams
^ I wrote rename the group leader, not the new member.
Yes, but the cause of the issue is that new group members are incorrectly added with the group leaders name instead of the name you specify for it in the blueprint.
Interestingly I was only able to replicate this on a 3 tier connection, using a 2 tier connection I had no issues adding new group members.
Ah, I was under the impression that perhaps there was another business object / specifics object in the existing OOTB content that had the same name as the group leader, rather than that the new one was getting saved with a different name than configured.
That's why I was saying rename the group leader; I assumed there was an existing group member in at least one culture / view in the OOTB content that for some reason had the same internal, plural or alias name.
If it's specific to the new specifics being saved under the group leader's name every time regardless of configuration... You'd continue seeing this error every time you created a new specific form, and have to rename the group leader every time instead of perhaps just once if it were a content issue.
I don't know which of those two situations it is. Haven't spent that much time on it.
This isn't new to 9.3x. I've run into a problem where the system name of new specifics defaults to "Specific" and then at publish it fails. If I then manually update each system name and save, it corrects the problem. I think I first ran into it in either 7 or 8. I thought it had been fixed, but guess not.
This is separate from that issue; on previous versions, specifying the text for that name mitigated the issue.
On this version, you can type it out correctly in a way that wouldn't have caused a problem previously, and still run into errors - Errors that may not be immediately clear on how to resolve.