Weak tools exist for SF deployments which don't access all required objects thereby requiring manual work and frequent org corruption occurs.
Our platform is more visual and user friendly then ANT which requires a developer to make the deployment whereas we could leverage clean UI to extend that to an administrator if frequent deployments are needed ( Dev -> QA -> UAT -> Prod ). This is very time consuming and nearly impossible during agile / scrum projects.
Description
One of the biggest advantages to using Salesforce is not only that it provides an excellent UI for viewing and analyzing data but also all the automation the platform has to offer such as flows, email alerts, workflows, managing profiles / security, and custom metadata. Currently, if a deployment is to be done in Salesforce there are a few popular options, but the most popular is Change-sets. Change-sets are incredibly time consuming, and aren't able to transfer over all files in an org. It doesn't transfer over records, metadata, profiles, and many configurations. Ant, which is another popular deployment tool is configurable but requires a more technical user to operate.
What's currently being done
In a project with multiple stages of development such as dev, QA, UAT, and Prod many deployments are required and if the team follows an agile scrum methodology then deployments happen multiple times a week and frequently break components in the inbound org. Deployments using either two of the most popular methods are incredibly frustrating and difficult to visualize. Having worked extensively with Salesforce and seeing those problems being manifested I think our platform could act as a more user friendly, feature rich deployment method and therefore fill that gap.
Benefits & Risks
Digging would have to be done to ensure the feasibility of this proposal. Since this is such a frequently complained about issue in the sales-force ecosystem I believe there is a potential opportunity for Elastic.io to capitalize on. I'm also not sure what the bandwidth restrictions are on the platform because these deployments move a significant amount of files, and therefore may be expensive from a resource perspective if the payout isn't high enough based on the market size ( which is huge based on the growing number of Salesforce projects / development in recent years ). This could also be an opportunity to reposition the platform as a deployment resource which could be added to the road-map if there's sufficient buy-in from management
Customer Base to be addressed
Currently our platform is shaping to require a fairly technical user to operate if the scale of the integration project is quite large. This would be an opportunity to help out the non-technical administrator to do deployments from orgs without having to understand all the mechanics behind sf objects or XML.
Highlights
Description
One of the biggest advantages to using Salesforce is not only that it provides an excellent UI for viewing and analyzing data but also all the automation the platform has to offer such as flows, email alerts, workflows, managing profiles / security, and custom metadata. Currently, if a deployment is to be done in Salesforce there are a few popular options, but the most popular is Change-sets. Change-sets are incredibly time consuming, and aren't able to transfer over all files in an org. It doesn't transfer over records, metadata, profiles, and many configurations. Ant, which is another popular deployment tool is configurable but requires a more technical user to operate.
What's currently being done
In a project with multiple stages of development such as dev, QA, UAT, and Prod many deployments are required and if the team follows an agile scrum methodology then deployments happen multiple times a week and frequently break components in the inbound org. Deployments using either two of the most popular methods are incredibly frustrating and difficult to visualize. Having worked extensively with Salesforce and seeing those problems being manifested I think our platform could act as a more user friendly, feature rich deployment method and therefore fill that gap.
Benefits & Risks
Digging would have to be done to ensure the feasibility of this proposal. Since this is such a frequently complained about issue in the sales-force ecosystem I believe there is a potential opportunity for Elastic.io to capitalize on. I'm also not sure what the bandwidth restrictions are on the platform because these deployments move a significant amount of files, and therefore may be expensive from a resource perspective if the payout isn't high enough based on the market size ( which is huge based on the growing number of Salesforce projects / development in recent years ). This could also be an opportunity to reposition the platform as a deployment resource which could be added to the road-map if there's sufficient buy-in from management
Customer Base to be addressed
Currently our platform is shaping to require a fairly technical user to operate if the scale of the integration project is quite large. This would be an opportunity to help out the non-technical administrator to do deployments from orgs without having to understand all the mechanics behind sf objects or XML.