Hi Manu,

Thank you for your questions :)

We really appreciate them and they are interesting for us.

We are going to improve the deployment functionality but these changes will be related to comparing of local and remote organizations.

Right now we have no plans to implement an ability to deploy separate fields of an object, however, I've added this to our backlog, and we will consider adding this feature.

May I please ask you to describe your use-case how you handle such deployment with any other tools? This will help us to understand how we can manage this process.

Thank you for your collaboration.

Regards,

Kate

Of course.

I have added custom fields to the Lead object on my development sandbox.

I want to deploy these custom fields to my qualification sandbox.

I use the welkin suite deployment tool which correctly detects differences on the Lead object and shows me the override option.

The problem is that my Lead object has managed package fields, and another developer working on the development sandbox has updated the managed package.

Managed package fields are different between the orgs so the deployment tool tries to apply these changes which result in error: "Cannot modify managed object".

For the moment I handle this problem using salesforce changeset to apply only selected fields changes.

Maybe a simple solution could be to skip managed package fields.

However it could be nice to choose which fields to deploy.

I hope my explanations are clear.

Thanks.

Regards.

Manu.

Hi Manu,

Thank you for sharing your ideas with us and thanks for the detailed description of the situation you are facing.

Right now we don't have such option in our plans as it is not a very common case and, to be honest, we're not sure yet how we can resolve such kind of situation. Because in general if deploying changes with API's and not with the changesets the whole object is treated as a single item without further breakdown to fields, so we're not able to "simply" strip out some of the fields and deploy. This why we'll need to investigate possible workarounds, so I can't promise that we'll implement such functionality in the nearest future.

From another point of - we are thinking about providing functionality for working with Changesets directly from the IDE, so in case we'll do this option earlier it might be a good workaround in your case :)

Thank you,

Vladimir

This is a critical piece of functionality.  Having to use changesets or manually recreate fields to avoid deploying the entire object is a significant setback in the development process. This capability should be possible to acheive. Another deployment tool called Metaforce can do this.

Hi Avi,

Thank you for your post and for sharing your feedback on the current topic.

We will include your input into prioritizing of the feature requests from our users, and we keep our eye on how/if we can implement this functionality.

If you have any other questions or suggestions, please share them with us - we'll be happy to hear them.

Have a nice day!

Regards,

Kate

Hi, 

I would like to add that this isn't so rare because ... we do it too!   We often only want to deploy certain fields.

Today, the way we do this is we manually edit the Package.XML file that is used by the CLI  (and ant)  to push just the changes in the package.xml file.

I'm wondering if, under the hood, Welkin Suite creates a package.xml file that it feeds through the CLI to accomplish a deployment ?

If so,  maybe a new filter option to allow us to drill down into fields of an object and select/deselect them during deployment ... OR an option to manually edit the package.xml file that is used during the actual deployment. 

Anyway, this would be a really great feature!

Thanks,

Jim

Here's how I worked around it:

In 1 solution I have a DEV project and my SANDBOX project.    I wanted to deploy changes to just 2 fields  from DEV to SANDBOX.

So I found those two fields in the object XML in my DEV project,  and opened the same object in my SANDBOX project.   I found + replaced the lines, saved, and then deployed to my SANDBOX instance from my SANDBOX project.  

So, it wasn't actually a deployment from  DEV ==>  SANDBOX,  but it did the trick.  

Great product Welkin, I'm really happy so far!

Hello Jim.

Thanks for the awesome workaround, Jim! We work hard to meet expectations like yours, and we’re happy to hear we hit the mark for you. Come back and see us soon. Cheers!