Question on "Merge Data" option when it comes to C...
# suitescript
e
Question on "Merge Data" option when it comes to Custom Records in a bundle (see thread)
We have a custom record in our bundle, and we created the first ~5 records and need them to exist in all clients accounts (clients are welcome to create additional records after the initial 5) The 5 records we created in our account that we use to package and distribute the bundle are as follows: Internal ID: 1 Name: One Internal ID: 2 Name: Two Internal ID: 3 Name: Three Internal ID: 4 Name: Four Internal ID: 5 Name: Five However, when we package and push the bundle to clients accounts, they come in differently... For Example: Internal ID: 1 Name: Four Internal ID: 2 Name: Three Internal ID: 3 Name: One Internal ID: 4 Name: Two Internal ID: 5 Name: Five We have logic in our other scripts that check for this record with ID of 3, thinking it's the record with a name of "Three" but that's not always the case in client accounts. Wondering if anyone has any information on how we can prevent this from happening? Our current intended workaround is to use the bundle install script to find and fix records 1-5, but it feels like there should be an easier way?
watching following 1
e
Strange. I don't have a suggestion for a fix or anything. If you do have to go the Bundle Installation script route, I might remove the instances from the bundle and create the records from the script.
e
The only catch there is if the client already created some additional records (like 6-10) My analogy falls apart here, as the custom record are not actually 1-5, but far more complex records with many fields on them.
The bundle install script to find and fix records 1-5 is working, so I'll stick to that for now. (as always) Appreciate the insight!
Even more fun- just pushed to clients account and it skipped internal ID 4 all together.... So when I tried to update internal ID 4 to "Four"...
RCD_DOESNT_EXIST
BLEHHH
c
You could add a checkbox to the records that let you know its a required record and do a search for those required records and you'll have them. The IDs may or may not match but you could use the name in this situation too
e
Yes, seems like the ID is unreliable. Perhaps give them a unique value in the
name
or any other field that you can key on to identify which record is which.
externalid
perhaps
e
Yes, seems like the ID is unreliable.
^ My worst nightmare
But I do like the idea of using
externalid
e
^ My worst nightmare
Right? If there is only one single value that must be reliable, it's that one