Turns out my issue was due to using subfolders. Do...
# sdf
t
Turns out my issue was due to using subfolders. Don't use subfolders in SDF deployments
e
Interesting. I have never had an issue with them. I always organize my Objects folder by type, and my SuiteScripts folder by feature. Haven't ever had trouble with it so long as I didn't make a mistake in
deploy.xml
e
Same here, I have folders and sub-folders under the FileCabinet/SuiteScripts folder and haven't had any issues.
z
I don't agree with that. All my projects are organized with folders and subfolders, especially Objects.
Could you share your issue, please. Maybe is there something special
n
I also disagree. Using subfolders for a while now.
t
Hey i'd been using them for over a year, turned out it was an issue for the first time this time around
currently bushwacking through errors, will revisit after figuring out why a workflow can't have a value of "2"
a
only referring to the
objects
subfolder structure obviously
suitescript
folders are not an issue
the original issue was posted here too and is another thread with only the two of us on it.
how many of you are writing suiteapps vs. account customizations?
I've found if you're repeatedly deploying to the same account then everything is fine, but when you switch to do a clean install in a new account without any of the objects pre-existing then the order things get created matter, because if you reference something that doesn't already exist in the account and it didn't start to process it in the deploy yet, then it will think it doesn't exist and complain
👍 1
wondering what you're all doing in your deploy.xmls? maybe there's a certain order of subfolder you can use there that means that things get created in the correct order?
e
deploy.xml
goes in order of appearance, and I don't trust
Objects/*
to do the correct order, so my typical order is Files > Lists > Fields > Records > Scripts > Workflows. I avoid Forms and Searches with SDF.
☝🏻 1
👍 2
😆 1
a
wrt to forms and searches, I know that was true a few years ago, but I've not found them to be so painful recently, I'm still wary of using SDF with them but in practical terms seems like its mostly fine now? Or have I just been lucky? anyone have recent horror stories?
t
@erictgrubaugh I've found forms will never be easy but in development accounts with not a lot of customization its 100x easier. With regard to saved searches the drill down fields always screw things up especially dependencies. Once I figured that out its been a lot better.
ALso again the issue is I'm making a suiteapp so I have to include this stuff especially once its in the marketplace and needs to work on a one click install
👀 1
n
Wait til you have to migrate datasets 😉 they need a workbook. Both datasets, workbook, formulas, pivot, etc need their own translation... And then the order in deploy.xml to be respected (I'm not even sure what's the correct order).
😬 1
t
Fortunately and unfortunately most people don't use those still. Far better than saved searches
e
My suspicion remains that you need to explicitly set the right deployment order in
deploy.xml
. Without seeing yours, it's hard to be more specific.
💯 1
a
should probably just test it but I'm busy 🙂 it should be possible to setup circular references even with deploy order by type being followed.... if your custbody field is of List/Record type of your Custom Record and your deploy.xml has Fields > Records, wouldn't that break, or require multiple deployments at least?
e
Potentially, but that's likely the exception, not the rule, and it's pretty easy to manage the exceptions once you have the base order set.
The primary takeaway should be that if you are having deployment order issues, then
deploy.xml
is the tool you have for correcting those issues. It's nice to be able to be really vague in
deploy.xml
, with something like
Objects/*
or subfolders by type, but that's not always possible. For the cases where that isn't good enough, you can get as specific about the order as you want/need.
💯 1