I'm reaching out to gather insights on managing workflow deployments within our community. Recently, our team transitioned from SuiteBundler to SDF for deployments, and we've noticed a marked ease in deploying scripts. However, when it comes to integrating other elements like Workflows and Custom Segments, the process becomes more cumbersome. One particular challenge we've encountered is dealing with Account Specific Values (ASVs). While the VS Code extension allows us to overlook ASVs during deployment, the Webstorm Plugin lacks this feature. I haven't yet explored how the CLI approach handles this. I'm curious about your strategies. Do you manually document the actual values, amend the ASVs in the XML files, and then execute the deployment? Or do you opt to disregard the warnings, rely on the SDK to manage the process, and then make any necessary manual adjustments to the workflows through the UI post-deployment? I'm keen to learn from your experiences. Perhaps there are methods or practices I've yet to consider. How do you navigate these challenges?

Actually, the Webstorm plugin does support warning on ASVs rather than stopping, it's just a project-by-project setting.

Glad the transition has at least made scripts easier! I agree that Workflows and Custom Segments are painful, so are Saved Searches and custom Transaction Forms in particular. I typically do not use SDF to deploy these partially- or poorly-supported Objects, but I do use SDF+git to back them up, in case I need to restore them at some point. I will regularly sync the Objects in the repository with their Production state using the

object:update

command. I put the XML definitions for these Objects in their own folder (e.g.

src/Objects/Searches/

), and I exclude those folders from my

deploy.xml

. Every team I've worked with has treated ASVs as warnings, not errors, and I do the same for my own work. FWIW, in the CLI, this is handled via an option on the relevant commands like `suitecloud project:validate --accountspecificvalues WARNING`; it defaults to

ERROR

, but I typically override that behavior in my

suitecloud.config.js

file.

@Jordan Patterson hmm, let me check that. Thanks! @erictgrubaugh but what is then the point of a “backup” since the XML of the object contains ASV elements? The only way to do it “properly” is before committing the XML file adding the actual values. In case of a change done by a user you can then start all over again

Because I treat ASVs as warnings, that doesn't stop me from deploying those Objects if necessary.

Oh really?

Yes, that's the intent of the ASV. When you set them to warnings and deploy, that value will be left alone

I will sure do this weekend 😃

I feel like treating ASVs as errors would cause a ton of headache

@erictgrubaugh Can you share your

suitecloud.config.js

?

Here's my default config file; I go over all the pieces in my sdf course.

@erictgrubaugh I tried this with a custom record with specific filter values on a field. When I leave this with the ASV's as fldfiltersel, the deployment fails with a Details: Please Enter a Filter Value.