Building Workfront projects from closed deals in Salesforce is something that sounds like it should be simple and easy. However, if done manually, it becomes a time-consuming, error-prone process. Even if your team creates their own service in order to perform the process automatically, that’s still time that could have been used working on more important projects. It’s an even larger time and effort investment once something changes and the service breaks. No matter how confident you are, the hard-coded solution will always break eventually.
Instead of dealing with the trouble that hard-coding causes, Azuqua offers a platform that is agile enough to create complex microservices while keeping them stable through updates and changes to products.
Below is the process for solving this Salesforce to Workfront issue in an Azuqua FLO in order to demonstrate just how fast you could have this up and running.
First, Azuqua’s FLO designer will want to know when to start the FLO. For this one, we will need to choose the Salesforce application in the “Application Event” section. You also have the option of scheduling a FLO to run at certain intervals or making a FLO only run when it is manually run or called by another FLO. This enables you to use Azuqua’s platform to build complex and powerful microservices quickly and easily.
Once you have selected Salesforce, click the “Updated Field” option in order to move on to the next step.
Then, we will need to use the “Updated Field” card to see whether or not the Close Date has changed in any of our Salesforce opportunities.
Next, you will be brought to the Data tab of the card. The cogwheel in the bottom right of the card can be used to change the data fields being pulled into the FLO. We’re just going to bring in some basic stuff like the Name and Description for the Opportunity. Also, we’ll need the StageName for the next section.
Now, click the Add Function button, navigate to the Control section, and then choose the “Continue If” function. With this function, we will be checking to make sure that the opportunity is actually a “Closed Won” deal.
Here we drag in the StageName from the Data tab of the card in Step 2 and check that it is equal to “Closed Won” to try and continue the FLO to the next step. If it is not, the FLO will stop here.
Next, we will add a Workfront action to the FLO.
Select Workfront in the Add Action menu and then select the “Search for an object” card in the list.
In the “Search for an object” card, we need to first establish that we’re searching for Projects in the Options tab (to the left of the Data tab). After that, the input fields you choose will determine what the FLO searches the Workfront projects for. In this case, we have decided to use a custom Workfront field for the Salesforce ID. Then we drag and drop the Salesforce ID we got in steps one and two into the field.
Now, if everything is running correctly, this should return a blank Workfront ID. If not, that means that there is already a Workfront project for this Salesforce opportunity, which would be an error.
Now it’s time for the big If/Else card. This does the heavy lifting in this FLO.
In the Conditions section, we need to make sure that the Workfront ID we got from the search came back blank (which means there is no Workfront project with that Salesforce ID yet). So we drag the ID from the Search card into the If/Else conditions and then leave the second field blank.
This is the busiest step of them all, but by this point you should be a bit more familiar with the way adding cards works in Azuqua. To add a card inside an If/Else statement, you can either make them separately and drag them in or you can click the plus buttons along the top of the If branch area.
So, this If branch should run if the Workfront ID is blank (see Step 7). Assuming it is, this branch creates the project, attaches a template to it, and updates the project’s info.
- Creating the project is similar to searching for one (see Step 6). In the “Options” tab (next to “Data”) we need to specify that we are creating a Project and not some other type of object. Once that is set, we can specify which fields we want to fill in the new Project’s information. Here we are only doing Name and Description. We also want Salesforce ID but that is not a default field in Workfront, so we will add that separately. For now, Name and Description are fine, but obviously you could add whatever other fields you needed.
- Next, we attach a template to the new project. The project ID is specified by dragging the Output ID from “Create an object” into this “Attach Template” card. Then, we copy and paste our template’s ID from Workfront into the empty field.
- Finally, the new project is updated with the Salesforce ID. Since the attached template allows the project to accept the Salesforce ID field, we can add that in order to prevent duplicates in the future (see Step 6).
As far as a successful execution of the FLO goes, that would be the end of it. But we also have to account for the Else branch of the If/Else card. What happens if the Workfront ID isn’t blank?
In this step, we specify what happens in the Else branch of the If/Else statement. Just for example, we’re going to have it send a simple email, but it could really be anything you needed it to do.
The Email Relay is one of the many email functions that Azuqua contains and it is the simplest way to just send a basic email. In the “to” field, you put the email you want to send it to. Then in “subject,” again, anything you want. And the same goes for the “body” field.
For the body section, we used the ID that the search found in order to demonstrate two things. First, you can drag and drop variables into things like email fields, not just functions. Also, we’ve included the line from the X-Ray feature to specify that the ID we are using here is a separate ID from the one right above the Email card. We’re pulling the ID returned from the search in Step 6 and NOT the ID created in Step 8.
This would send out an email notifying someone of the issue as well as attaching the ID so it’s easier to track down the issue.
And that’s it! Our FLO is complete. Not only that, but if we decided we didn’t like something or wanted to add more capability, it would be simple and easy. If something like this was hard-coded, the time and effort that would go into changing it every time it needed to be updated would never be worth the hassle. Azuqua’s platform is able to set something like this up in a way that is flexible, scalable, and powerful all at the same time.
If you would like to try it out yourself, you should sign up for our free trial here. »