Sonoma Partners posted a great article about Enabling Mail Merge for Upgraded Custom Entities
where they export an entity, look at the XML, modify one of the tags,
and then reimport the XML. Until their post I had not seen this new XML
tag so I was very excited to see this great find because I was actually
pretty disappointed about what I could and couldn't use with Mail Merge.
My post today builds on this a little and I'll show you another use for looking at exported entity XML.
I once made a custom entity with literally 150+ fields under the assumption that no activities or notes would be needed on the custom entity. During a screen review I was told everything looked great but they wanted to attach things to the entity...and I then thought about recreating all 150+ fields, placing them on the form, and applying the scripts...again. I was not excited about doing that at all because as you may or may not know, once you create an entity and set it up with or without Notes and Activities, it's set, there's no checkbox to click to get that functionality added back after creation.
After a bit of searching and a random idea about reimporting my XML into an existing entity I found my answer. I exported the entity XML hoping to import it on top of an existing custom entity that had Notes and Activities enabled, I got an error however regarding type codes not matching or already existing. So, I went through the XML and as I was searching I found some tags (that you can see very apparently in one of the Sonoma screenshots of their post) called:
HasRelatedNotes
HasRelatedActivities
I then had a crazy idea. I deleted my old entity, published, changed the HasRelatedNotes tag to True (or 1), imported the "new" entity and I then had all 150+ fields, form setup and scripts as before only this time with attachment capabilities.
Now take this one step further and you could even copy an entity by modifying a few tags here and there so that the "copied" entity has a unique name, entitytypecode, and identifiers. I've done this a couple of times and I have to fight errors about things already existing but for the most part the errors were decent in letting me know what I has messed up...not necessarily where though. It's great for larger custom entities that need to be extremely similar. I don't come across this all that often, but it has come up and has saved me hours of time for my clients.
Maybe not the most user-friendly way of doing things but it is much faster and not nearly as tedious as reentering hundreds of fields and hoping you get all of the types, max vaules and defaults correct a second time.
Hope this helps someone else who could be in dire needs of a quick solution to a similar problem that I ran into.
My post today builds on this a little and I'll show you another use for looking at exported entity XML.
I once made a custom entity with literally 150+ fields under the assumption that no activities or notes would be needed on the custom entity. During a screen review I was told everything looked great but they wanted to attach things to the entity...and I then thought about recreating all 150+ fields, placing them on the form, and applying the scripts...again. I was not excited about doing that at all because as you may or may not know, once you create an entity and set it up with or without Notes and Activities, it's set, there's no checkbox to click to get that functionality added back after creation.
After a bit of searching and a random idea about reimporting my XML into an existing entity I found my answer. I exported the entity XML hoping to import it on top of an existing custom entity that had Notes and Activities enabled, I got an error however regarding type codes not matching or already existing. So, I went through the XML and as I was searching I found some tags (that you can see very apparently in one of the Sonoma screenshots of their post) called:
HasRelatedNotes
HasRelatedActivities
I then had a crazy idea. I deleted my old entity, published, changed the HasRelatedNotes tag to True (or 1), imported the "new" entity and I then had all 150+ fields, form setup and scripts as before only this time with attachment capabilities.
Now take this one step further and you could even copy an entity by modifying a few tags here and there so that the "copied" entity has a unique name, entitytypecode, and identifiers. I've done this a couple of times and I have to fight errors about things already existing but for the most part the errors were decent in letting me know what I has messed up...not necessarily where though. It's great for larger custom entities that need to be extremely similar. I don't come across this all that often, but it has come up and has saved me hours of time for my clients.
Maybe not the most user-friendly way of doing things but it is much faster and not nearly as tedious as reentering hundreds of fields and hoping you get all of the types, max vaules and defaults correct a second time.
Hope this helps someone else who could be in dire needs of a quick solution to a similar problem that I ran into.
No comments:
Post a Comment