As the title suggests, we’re trying to better understand the behaviour of the PLACE_TYPE variable. We’re also wondering whether there’s a PERSON_TYPE counterpart that we may not be aware of.
After reviewing the generic form doc, we noticed some differences between the documented approach and our current setup.
In our project:
We have a generic PLACE_TYPE-create/edit form and a place-types.json file in the contact folder. These haven’t been modified since the initial repo setup.
We also maintain type- and level- specific contact forms, which we update regularly.
What’s interesting is that although we use type/level-specific create/edit forms (rather than these generic forms), we’re still able to access and use the PLACE_TYPE variable within those forms. And seemingly have for a long while. It resolves correctly, even for some newer place types that are NOT defined in the place-types.json file (maybe worth to note that it’s just the normal types with a “ff_” prefix (feature flagged)).
What’s nice is that it makes it easier to share pieces of functionality across forms with fewer edits than expected. Important to note, parts are reusable - not the full form.
Even more interestingly, person forms appear to exhibit somewhat similar behaviour. This one threw us a bit. While using PLACE_TYPE directly (e.g., as the group name of the data persistence block, as we do for places) does not seem to work for people, we are still able to reference values FROM the persistence block successfully.
Looking at that linked code does explain the behavior you are observing:
It is applied to every contact form. Not just place forms and not just forms generated from the PLACE_TYPE-create/edit.xlsx files.
It does a blind regex replace of 'PLACE_TYPE' with the type value extracted from the form’s file name. (And not from the place-types.json). I suppose this is why your custom types are working.
That being said, I would stop short of calling this “expected behavior”.
On one hand, it has been like this for 9 years, so maybe the chances of this changing anytime soon are pretty low. On the other hand, from my perspective I would consider this PLACE_TYPE replacement logic to belong to the PLACE_TYPE-create/edit.xlsx workflow and I would not guarantee it will continue to work in any other context.
This is very interesting! When you say “reusable” do you just mean that you are copy/pasting blocks of rows between xlsx files? For years we have been trying to figure out ways to reduce the maintenance effort in these forms. I think this was the original goal of the PLACE_TYPE-create/edit.xlsx functionality. Unfortunately, the contact hierarchy structure/complexity looks very different now than it did 9 years ago and I am not sure that feature is providing much value anymore.
I wonder if it would be best to introduce a generic CONTACT_TYPE placeholder value that would function similar to how you are using PLACE_TYPE currently, but would not be tied to or dependent on the PLACE_TYPE-create/edit.xlsx workflow? (Maybe we could even deprecate/remove/replace that workflow…)
It seems like if this functionality is providing value, we should support it.
That being said, it has “worked” for 9 years now, so… 
On the other hand, from my perspective I would consider this