Ignition proposal accepted -> create a client in Glide

This integration will create a new client in Glide (so long as that client doesn't already exist) when a proposal for a new client is accepted in Ignition.

If you create prospects in Glide, then you would instead create a client in Ignition when a prospect is created in Glide.

Step 1 - Set up a Zap to catch Accepted Proposals

This step will set up a Zap which will be triggered immediately when a proposal is accepted in Ignition.

We will do some filtering here to ensure that we are only dealing with new clients as this integration is not intended to capture renewals by existing clients.

We will then send the relevant data to Make where, in Step 2, we shall use this information to create a client is Glide.

1a) Create a new Zap

Create a new Zap and set the trigger app to be Ignition and the specific trigger to be 'Proposal accepted'.

You can use Zapier's Copilot tool to speed up the creation of the Zap, as pictured below.

The Zap should look like this:

1b) Configure the Ignition step

Set the trigger event to Proposal accepted and choose the appropriate Ignition account. If you have not previously used Ignition in Zapier, then you will be prompted to Log in. Once completed, the Zapier step should look like the screen grab below.

Click on Test and Zapier will pull through the data from the most recently accepted proposal in your Ignition account.

1c) Filter out accepted proposals for existing clients

This integration is only interested in capturing new clients and in this step we seek to filter out proposals that relate to existing clients.

You can add as many filters to this step as you need. I have proposed the two filters listed below. The official Is Renewal field will filter out renewals so long as the previous proposal was on Ignition. The first proposal on Ignition for any client will not appear as a renewal, even though you may have worked with that client for many years, so you will need at least one other filter.

The Proposal Name can be set by you and is not visible to the customer, so this is a convenient place to enter a term that will signify that the proposal is not for a new customer.

1. Filter out where the Ignition field Is Renewal is False. Use the boolean filter here.
2. Filter out where the Ignition field Proposal Name contain the string Renewal.

The filter step will look similar to this.

1d) Send the relevant data to a Make webhook

For this step we are using the Webhooks by Zapier app. We will select any data that we are interested in and send it to Make.

I have decided to make use of the fields listed below. In each case, I have explained what I plan to do with the data and I have confirmed whether it is mandatory for the main objective of the integration to work, or more optional.

In the Webhook by Zapier step, you need to set the following options:

The data setting should appear similar to this. The key names can be set to whatever you like.

Step 2 - Receive the data in Make and send to Glide

2a) Create a Make scenario triggered by a webhook

Create a new scenario in Make and use the Webhooks app for the trigger. This step will automatically generate a URL, click the Copy address to clipboard button and use in step 1d above as the URL.

Once step 1d is complete you can trigger a test in Zapier, which will send data from the example proposal to Make. This test data which you can then access to map fields in the remainder of the Make scenario.

2b) Create a row in a data store for this proposal

For this step, we shall use the Data Store module and specifically the Add/replace a record action. You shall need to click the button to Add a new data store, as pictured below in the red rectangle.

When creating a Data store you shall need to click the Add button to create a new Data Structure, as pictured below in the red rectangle.

When defining the data structure, add the following:

Click the button highlighted below to add each of the above items:

Returning to the Add/replace a record action step in the scenario, add a new record by mapping data from our Ignition webhook and setting the deletion date to 1 month from the current date. An example of the mapping is pictured below.

By now, assuming you are including step 2b, then your scenario should look like this:

2c) Deduce the client type using a router with filters

For the next module add a router, this option is always visible in the right hand side bar, as pictured below.

Ignition does not explicitly confirm the client type, so we shall have to make certain assumptions based on the client name. Of course, we can change this once the client is in Glide.

We have decided to use a router. This means that each client type wil have its own route from this point onwards. This makes the overall scenario look bigger but brings the flexibility to have modules that only apply to certain client types, or to configure modules differently for different client types.

It is probably also possible to remain on a single route by using some conditional logic, but we found this approach was less reliable in Make.

Once you have your router module, click the spanner icon to and then the Set up a filter option, as pictured below.

Our first filter will look to find Limited Companies. It does this by looking for the terms Ltd or Limited (case insensitive) AND by ensuring the term Limited Liability Partnership is not included (We do not need to worry about LLP as this does not include the term Limited).

The picture below shows how the filter should appear:

My second filter is to detect LLPs, pictured below:

My third filter is to detect PLCs, pictured below:

My fourth filter is to detect individuals, which I have done by looking for the terms Mr or Mrs, pictured below:

I then have a final fallback route, to capture clients where none of the above filters are matched. In this case, I have decided to treat them as Limited Companies. As noted above, this could be changed easily in Glide if the assumption transpires to be incorrect. The fallback option needs to be ticked on this route, as pictured below:

In our router system, it is important that the routes are in the correct order, as the first match will be accepted. If you need to change the order you can right click on the router module and click on Order routes.

2d) Add the Glide module to create the client in Glide

On each of your routes, add a Glide module and choose the Create a new client action.

All the modules will be largely identical, the Ltd module is pictured below and any instances where the other modules are different are explained below the image.

The differences to be aware of are as follows:

• Be sure to choose the correct client type in the drop down called Client type.
• We have used PI_{Ignition client code} as a temporary client code in Glide. You can change this once the client is created in Glide.
• When creating an individual, I have used the contact name from Ignition as it is most likely to be in the correct format (first last). This needs to be split between a first and a last name and pictured below is our suggested method to achieve this (if you expect names with 2 spaces or more, this would need modifying).

By now, assuming you are including step 2b, then your scenario should look like this:

2e) If you did step 2b then do this as well

The Create a new client step will have returned the Glide client ID of the newly created client. We shall add this to our data store so that we can easily link the Ignition proposal to the correct Glide client ID. This is essential if we want to be able to reliably activate services using Ignition's Service accepted webhook.

The Service accepted webhook(s) is triggered separately by Ignition so we can not consume the data in this same integration. We could assume our temporary client code is still associated with the Glide client (99% likely to be the case as these are fired just a few milliseconds later) but this approach is even more reliable.

On to each of your routes, add a Data store module and use the Update a record action. The key will be provided by the response to the earlier Add/replace a record step and we just need to provide the glideClientID value, which is available in the response from the client creation step. An example is pictured below.

Step 3 - Optional extra Glide steps

3a) Set the client email as Ignition's contact email

Add a Glide Set/update a client field (by Glide client ID) module to the end of each of your routes. The configuration for each of these modules will be identical, as follows:

• The Glide client ID is mapped from the response to the previous step (Create a new client).
• The Custom client field ID is available on the Database codes summary page found in the Config menu inside Glide. In my example below, the field code is 221. Yours may be different.
• The Value is mapped from the initial webhook step where Ignition will have provided a Contact email.

An example is shown below.

3b) Repeat the above for any other client fields

You could repeat the above step for any other useful data that Ignition has shared. I would consider doing this for the following:

If you need to create new custom client fields, follow the steps here: https://glide.helpscoutdocs.com/article/33-how-to-create-new-custom-client-fields

3c) Set the trigger date for the renewal process

If the contract signed through Ignition is for a set period of time, for example a year, then you might wish to have a recurring workflow system that handles the renewal process. This might entail a job being created a month or two in advance of the end of the contract, such that the account manager can contact the customer to discuss the renewal.

As this integration is creating a new client, we can safely assume that the trigger date field is empty and populate it. The process to do this is exactly as per step 3b.

I would recommend the trigger date be the literal contract end date and the workflow system be configured to create the job c. 60 days ahead of that date.