Maintenances

Introduction

Actito is committed to continuously improving its solution through frequent updates. On a regular basis, a new version of the platform is deployed in production, bringing in new contents, feature updates or bug fixes. Each update is announced through the notification center within the platform.

Most of the time, new features are added directly to existing applications.

But sometimes, a whole new solution is added altogether, taking the best of an existing application while being entirely rewritten in a new app. In order to move on with the evolution of the platform, the long-term plan is to have this new up-to-date module eventually replace the old one.

To guarantee you a smooth and transparent transition, such maintenances will be announced in advance on this page and through dedicated communications.

Tip

Updates are released separately on each environment. They usually occur on a Tuesday for the Brussels and North America servers, and on a Wednesday for the Paris server.

Maintenance calendar

The following calendar will summarize the schedule for each maintenance that may require users to migrate processes to a new solution.

Each specific maintenance will be detailed below.

Legacy feature

Replacement solution

End of service schedule

API Basic Authentication

API key and token authentication

December 31, 2022

Old e-mail engine

New e-mail engine

December 31, 2022

GET a list of profiles API call

V5 "GET List" or V4 "GET Single profile"

December 31, 2022

API Basic Authentication

The Actito API allows technical users to access most of the resources of your licence for technical integrations.

Since the release of the V5 of the Actito API in 2019, we have been promoting the use of the API Key authentication protocol to connect to our webservices.

Indeed, while V4 calls have been usable so far with both the Basic Authentication and API Key protocols, V5 calls have always been only available with API Key access, with the aim of generalizing the use of this protocol.

In 2020, Actito introduced a new app to allow licence administrators (Admin rights) to create API access themselves, and since then, we deprecated the creation of new BasicAuth users.

The next step is the end of service of the BasicAuth authorization method in the Actito API.

When?

As of December 31, 2022, it will no longer be possible to pass calls with BasicAuth credentials.

If you didn't start the process yet, we advise you to update your existing calls to the API Key protocol in order to continue using the Actito API past this date.

Why?

Authentication through API Key and Bearer Tokens ensures more security and flexibility in the API access management.

As base64 is easily decrypted, intercepting the Authorization header of your calls could allow an attacker to deduce your fixed API login and password.

With the API Key protocol, you avoid sending your credentials with every call. The API key is used to generate a Bearer Token that is valid for 15 minutes and serves as Authorization for your calls.

Any hypothetically intercepted token would be rendered meaningless after maximum 15 minutes.

How ?

Switching from BasicAuth to API Key first entails a modification of the base URL of your calls. See here for the domain used to access the Actito API through API Key and Tokens.

The main difference then consists in the use of the Bearer Token as Authorization header of your calls.

For more information on how to generate and use this token, please see our API documentation.

As for every call, the base URL to retrieve the token depends on your environment :

We advise not to hardcode the token renewal after 15 minutes, but rather to catch 401 returns and set up a renewal + retry system.

Tip

A recent expired token will return a 401 error, while an altogether incorrect one would return a 403 error.

Important

This does NOT mean that V4 API calls won’t work any longer. Only the authentication method is concerned.

This means that apart from the base domain and the Authorization header, there will not be any change in the path and the structure of your existing calls. V4 and V5 calls will continue to co-exist, but only through API Key authentication.

Deprecated e-mail engine

Since 2018, Actito has developed a new e-mail engine. It is an evolution of the 'old' module that retains its core features, while adding many new innovations but also implementing some existing ones differently. Indeed, the technology used by the old engine did not allow us to implement the upgrades that we wanted.

Since the launch of the new version, all development related to e-mail campaigns have been focused on the new engine, allowing Actito to present a refined tool with increased performance and heaps of advantages.

For these reasons, we will stop servicing the deprecated e-mail engine and transfer all licences to its new version.

When?

The end of service of the deprecated e-mail campaign engine is scheduled for December 31, 2022.

All licences need to be transferred to the new e-mail engine before this date and all deprecated e-mail campaigns will stop running.

Tip

The core engine is similar to the one already used for the SMS, Print, Call center, ... channels. So even if your licence still uses the 'old' engine, you may be already familiar with the newer interface philosophy.

What happens?

When the new e-mail engine is activated, you gain access to a new interface and its feature. The effect of the switch on your existing campaigns depends on their status.

  • All your Sent campaigns are transferred to the new interface. You keep access to the report and the interactions. You can copy a Sent campaign and it will create a new draft with the copy of the content and access to all the features of the new engine.

  • All your In progress scenarized campaigns are transferred to the new interface, but they continue to run on the old e-mail engine when they are triggered. They are flagged by the label [Deprecated]. You keep access to the report and the interactions but you can't use a [Deprecated] campaign in a new scenario. In addition, [Deprecated] campaign will stop working on December 31 2022. However, you can "correct" a [Deprecated] campaign. After your validation, this will transfer the campaign to the new engine with all its new features, all while retaining the content of your original campaign (see G. on the Checklist below for more details).

  • You should not schedule a campaign during the operation.

  • All your Draft campaigns will not be transferred to the new interface. If you want to keep a draft, we advise to save it as a campaign template or export its HTML content.

  • All your design and campaign templates are transferred.

  • Your sending and link domains are transferred and ready to be used. There is no deliverability impact to the switch.

What to do?

The activation of the new e-mail engine needs to be done by the Actito teams, but there might be some points of attention on your side depending on your usage of the deprecated engine.

To switch to the new e-mail campaigns engine, please run through the following checklist and give the results to your dedicated Actito contact person, who will schedule the operation with you.

If you answer YES to a question marked by an asterisk (questions A to D), we advise you to discuss the topic with your dedicated contact person beforehand. Some dedicated support projects may be required.

If you answer YES to a question not marked by an asterisk (questions E to J), some adaptation of your processes might be needed, but shouldn't prevent the switch. You can still discuss it with your contact person if you feel you'll need assistance. They will present you the possibilities to order a dedicated support project.

A. Do you use JSP templates in your licence?*

JSP e-mail are no longer available in the new e-mail engine. Only HTML can be used to code e-mails in the new engine. Any JSP e-mail that you want to continue using will have to be translated into HTML. Our teams can assist you with this process through a dedicated project.

B. Do you have the AMI add-on?*

The compatibility of your custom dashboards with the new engine should be analyzed with the AMI project managers.

C. Do you use specific apps (developed by the Actito service teams ) related to e-mails?*

Due to the custom nature of these apps, their compatibility with the new engine should be checked with our teams.

D. Does your licence have custom templates (created by the Actito service teams)?*

We advise you to request our service teams to check their recency and their compatibility with the new engine technology, such as for example the block library.

E. Do you use the "Planning" app?

The "Planning" app is deprecated and not compatible with the new e-mail engine. It cannot be used anymore.

F. Do you use API to trigger e-mail sending?

Calls now only works with the IDs or technical names of the campaigns.

The "name" setting to create an API campaign becomes the technical name: spaces and special characters are therefore forbidden (dashes and underscores can be used)

G. Do you have active scenarios / continuous campaigns, that you want to keep active after the switch?

It will not be possible to use migrated scenarized campaigns in new scenarios. If triggered, these campaigns will continue to be sent out using the old e-mail modalities. These old campaigns are recognizable by the label [Deprecated].

As of March 2022, it is now possible to "correct" [Deprecated] campaigns. After your validation, this transfers the campaign to the new engine with all its new features, all while retaining the content of your original campaign

All campaigns with the label [Deprecated] will stop working as of December 31, 2022. They will need to be corrected to the new version beforehand.

To do so, please view the details in the "How to correct [Deprecated] campaigns?" section below.

H. Are there standard exports on e-mail events in the licence?

As explained above, [Deprecated] campaigns are still triggered on the old engine. To make sure that events from both engines are included in the same file, existing exports will be updated.

These updated exports will switch from "Incremental custom" to "Standard" exports, which means that they will be directly available in the Manage Exports app (Datamart Studio > Manage Exports)

I. Do you use link domains in HTTP?

Your link domains host the images in the editor. This implies that images are not displayed in the preview of the editor if the link domain is still in http. This also has an effect on the display of the e-mail of the "heatmap" in the click report of the campaign. Even if it's possible to preview these images by accepting non-secure links in the browser, we strongly advise to purchase a SSL certificate and installing it on the link domains (see Securing your Link Domains).

J. Do you have added campaigns in a campaign group stored in a different entity than that of the campaigns?

In the new engine, campaign groups can only contain campaigns from the same entity as them.

How to plan?

  • Your drafts will not be transferred to the new engine. If you want to keep a draft, we advise to save it as a campaign template or export its HTML content.

  • No mass campaign should be scheduled during the switch. Before choosing the date of the switch, plan a 2 hours window in which you won't send campaigns.

  • Switches to the new e-mail engine are carried out on Mondays, Wednesdays and Thursdays. Please choose a date accordingly.

  • The documentation on the deprecated e-mail engine has been removed from the main documentation platform. You can now access the documentation of the new engine to get to know its additional features.

How to correct [Deprecated] campaigns?

After switching to the new e-mail engine, all your active scenarized campaigns will be migrated with the [Deprecated] status. Indeed, they continue to run on the old e-mail engine when they are triggered and they can't be used in new scenarios.

As these campaigns will stop working on December 31, 2022, it is necessary to migrate them to the new engine. This is done through the "correct" button, which is also available to update normal scenarized e-mails.

This action has 2 roles:

  • Allowing you to double-check the migration of all campaign parameters (such as personalization sources, ...).

  • Enabling you to use the new features of the new engine in your existing campaigns.

To start the correction, select the [Deprecated] campaign in the 'In progress' tab, click on 'More' then on 'Correct campaign'.

images/download/attachments/651362364/image2022-3-25_11-28-52.png

A pop-up will open. Confirm by clicking on 'Correct'.

images/download/attachments/651362364/image2022-3-25_11-29-53.png

This will create a correction draft. You will be able to go through and validate each step of the campaign definition.

If you abandon the correction halfway through before finalizing it, the campaign will appear in the 'Draft' tab, with the label [In correction], and an asterisk at the end of its name.

images/download/attachments/651362364/image2022-3-25_11-32-16.png


Correction walkthrough

While there will be little difference for the 'General data' and 'Target group', it is worth looking a bit deeper into the 'Message' step.

You will retain the content exactly as it was in the original, but you will gain access to the new features of the template editor, such as fonts, paddings or borders, and the module library.

Regarding the 'Personalizations' of your campaigns, there are a few changes that you should have in mind:

  • First of all, the format to insert a personalization is no longer $variable. Curly brackets are now mandatory and you should write ${variable}. Good news, all your existing personalizations have been updated during the migration!

  • The way to add personalizations on Custom Tables has also changed. It is no longer necessary to add the table to the targeting filter to use it in a personalization. Instead, they should now be added as 'Source' in the 'Personalizations' menu (see Personalizing an E-mail campaign for more details). This means that when you select what data point to use, "Consistent with the targeting" is no longer an option.

images/download/attachments/651362364/image2022-3-22_10-50-38.png

Instead, you can directly add selection criteria in the source, choose which field to order the data (instead of being restricted to "id"), or of course use the data that triggered the scenario.

images/download/attachments/651362364/image2022-3-22_10-55-27.png

For these reasons (especially if you used to select data "consistent with the targeting" on Custom Tables), we advise you to check the personalization sources of your migrated campaigns.

To do so, open the 'Personalizations' menu, turn on 'Expert mode', open the 'Data Sources' tab, and click on the icon next to the custom table. You will be able to validate that the data selection criteria are consistent with your campaign.

images/download/attachments/651362364/image2022-3-22_11-47-11.png

After validating the content and the personalizations of your campaign, you can test it again at step 4. Or go directly to the last step, where you will view a summary of all parameters.

At the bottom of the last step, click on "Correct campaign" to validate the correction.

Tip

No e-mail will be sent automatically when you click on "Correct campaign", as it remains a scenarized campaign. It will only finalize the correction.

images/download/attachments/651362364/image2022-3-22_16-9-36.png

Once the correction has been validated, the campaign will be officially considered fit for the new e-mail engine and no longer deprecated! This means it will have access to all new features, can be corrected again in the future and be used in new scenarios.

images/download/attachments/651362364/image2022-3-25_11-34-29.png

The campaign will remain functional in all old migrated scenarios, which will use the new version! Any targeting referencing the campaign will also remain fully functional.

Regarding the campaign report, it will aggregate the stats from before the migration with all the stats from future sent e-mails.

On the other hand, interactions available in 'View interactions' will be divided between pre- and post-correction. The button 'Old interactions' will allow you to view the interactions before the correction.

images/download/attachments/651362364/image2022-3-25_11-35-23.png

GET a list of profiles API call

The Actito API allows technical users to access most of the resources of your licences for technical integrations.

In addition to the call used to retrieve the information from a specific profile, there is a call to retrieve information from a list of profiles (up to 200), with the option to add some filter criteria on update/creation dates, or some search criteria based on any attributes of the profile table. This is the call with the base path GET /entity/{e}/table/{t}/profile

However, searching on non-indexed attributes with the potential of such a large response presents a performance and load problem. It was therefore decided not to maintain the "GET a list of profiles" call and provide some alternatives for its use cases.

When?

The "GET a list of profiles" call will be fully removed from the Actito API for December 31, 2022.

To avoid new usages, it was already removed from the developers documentation last year.

Which alternative?

V5 alternative

If your use case is to retrieve all the profiles who were created or updated recently, the closest replacement to this deprecated route is a V5 call to GET a list of profiles.

V5 uses the API Key authentication method. To use this call, you may have to switch from Basic Auth to API key + token (see above for the deprecation of Basic Auth).

Just like the former V4 route, the returned payload will provide all the attributes, subscription, segmentation and technical information for several profiles at once.

There are however differences when it comes to the criteria available to filter profiles :

  • Time based criteria : The main criteria used to filter these profiles will be based on the creationMoment OR updateMoment (not both at once). Thanks to the createdAtFrom/ createdAtTo and updatedAtFrom/ updatedAtTo query parameters, you can specify the time range for which you want to look up profiles.

By default, profiles will appear by profileId in ascending order, which is the equivalent of "oldest first". Therefore using the time filter is key to getting the most recent profiles.

  • Pagination : the pageSize parameter allows you to choose the number of profiles returned by the call. Like the deprecated V4 route, the default and maximum number is 200 profiles. The main difference and improvement here is the possibility to handle several pages ! The "page" parameter of the response gives you the number of profiles matching your criteria and the number of pages available, which allows you to retrieve the individual pages with the page query parameter.

  • Fields : the fields query parameter allows you to choose which fields you want to appear in the response payload. This is very useful if you want to limit the data you get in return, if , for instance, you only need the value for subscriptions, and not all the profile information. NB : the fields parameters is not used to make a search on the value taken by these fields. This means that a main difference between both calls is that a search based on the value taken by a non-unique attribute is not possible.

Good to know

The V5 Get a list of profiles route is subject to a specific rate limitation of 1 call per second.

Get a single profile alternative

Another use case of the deprecated "Get a list of profiles" call is to actually not retrieve a list of profiles, but a single profile with a search criteria on a non-unique field. This creative use of the "Get a list of profiles" call is not covered by the V5 alternative, as searches on non-indexed fields is not optimal performance wise, and it was not intended with this usage in mind.

The alternative to find a single profile is therefore to use the existing V4 call to "Get a profile". This call allows you to retrieve profile information by identifying through a key=value pair corresponding to any unique attribute of your database.

This may require an adaptation of your processes :

  • either an upstream search in your CRM to retrieve a unique profile identifier (like the e-mail address or a client ID) based on the field that you were using

  • or making unique the field used for the search criteria. Remember that in Actito, you can have multiple keys in your DB and that you can update the unicity of an attribute in the "Manage DB structure" app.

images/download/attachments/651362364/image2021-12-2_11-46-39.png