Changes since Execute 21.1.215

Execute’s new Document Fetch APIs provide a streamlined way to bulk extract documents from Execute.

• A single streamlined API call vs. the Login > Run Report > Logout call for the current APIs.
• Returns ALL data for request documents in a nice friendly machine readable JSON form.
• Supports including calculated field values in the returned data (popular request from User Voice).
• Easily filtering to return only documents modified since a provided date (makes it much easier to keep a remove warehouse up-to-date).

Note: These APIs require the Execute Advanced Data Export (OData) module license.

More information can be found in our New Postman-based API documentation.

When configuring email reminders and notifications, administrators can now…

• Allow users to opt-out of receiving the notification/reminder by setting the Allow Opt-Out field on the notification/reminder to “Yes” (by default, users are not able to opt-out of reminders/notifications that they are included in)
• Allow users to opt-in to receiving the notification/reminder by adding the new notify subscribers block to the reminder’s Recipients rule. i.e.

Users are then able to adjust their email preferences from the new “Email Preferences” menu item under their name in the top-right of the Execute screen.

If you’ve ever found yourself looking at a report in Execute’s browse screen and thought to yourself, ‘Gosh, that ain’t right. I need to update that!’, only to be slightly deterred by the prospect of actually opening the Well, AFE, Job, etc. to make the change… Have we got a thing for you!

Users can now update individual values or entire columns right from the browse screens throughout Execute!

From the browse screen, users can now click the toolbar’s pencil icon to enable bulk edit mode. This puts a pencil in each editable cell in your browse report which will allow updating the cell without leaving the report. In addition, the new “Bulk Update” option under the column dropdown allows a user to update the entire column (respecting any filters you have, of course).

This new functionality respects the user’s edit permissions and will only allow updates to data they could have changed normally.

Here is a quick demo:

This release includes support for Peloton’s new 2.0 APIs (affecting Peloton SaaS customers).

Peloton has announced their plans to deprecate their existing APIs (used by previous versions of Execute’s integration with Peloton SaaS) by the end of February.

Customers who wish to use/continue to use this integration must:

1. Contact Peloton support and request written permission to enable this integration (cc’ing Execute Support). Peloton requires customers obtain written permission prior to integrating with third parties.
2. Upgrade Execute to this version or later.
3. Work with Execute Support to update their configuration to use the new integration.

With this update, Execute now includes support for integrating with the following document management systems:

• Quorum’s DynamicDocs
• Microsoft’s SharePoint

Execute now supports multiple pluggable “AttachmentStores” which can selectively take over the storage of attachments.

• Each attachment store can decide which document(s) (AFE, Well, …) it should store attachments for.
• Execute supports pushing and maintaining additional meta-data for each attachment to help searching/sorting/categorization/etc. in the document management system.

This gives a great deal of flexibility. For example, you can use SharePoint for “approved” AFE attachments, DynamicDocs for Well-level attachments, and the built-in storage for everything else.

Plugins for these integrations are found under plugins_available\integration\product_integrations\document_management.

The Execute Integration Agent, which facilitates integrations between Quorum-hosted Execute and on-prem systems, is now packaged with Execute and will, in the future, automatically update itself as required.

If you are currently running the Integration Agent, however, you must manually update it as part of taking this Execute update. If this step is not taken, integrations using the Integration Agent will be broken.

You can download the latest Integration Agent installer from Execute’s Tools > Configuration > Integration Agent Configuration menu.

You’ll need to stop the current version of the Integration Agent (under your Windows Services panel).

You can then run the downloaded installer on the server hosting the Integration Agent and install the Integration Agent over top of your existing Integration Agent installation’s root folder.

Note that because the installer was downloaded from the web, you may need to unblock it before you’ll be able to run it by right clicking the downloaded file, selecting Properties, and then Unblock.

In this update, we’ve added a new Job Scheduling mode (inspired by Generwell’s similarly named module) to Execute’s Operational Schedule. This new mode simplifies the process of adding jobs (from the Jobs module) to a schedule, adjusting their timing, and feeding that updated timing back into the Job workflow.

• Each schedule view can define a report which provides a list of candidate jobs (the job hopper) that can be added to that view.
• A scheduler can select one or more job(s) from that report and add them to a resource on the schedule.
• New Schedule Activity Relationships configuration allows you to define the relationships between activities (Completion happens after Drilling, etc.), so that appropriate dependencies will automatically be created when scheduling Jobs.
• Updated timing from the master schedule will automatically feed back to the new “Job Start”, “Job End” and “Duration” fields.

Note: Execute previously included “Sched Start” and “Sched End” fields which were barely used (only set when creating a Job from the schedule). The new Job Start and Job End fields replace these and the old fields will be removed in a future update.

Execute now includes the following functionality in beta (pre-release) form. This functionality is optional (off by default) and has not yet undergone our usual stringent QA process. We have released it so that interested customers can start exploring it, planning adoption, and providing feedback.

We do not recommend using these new capabilities in production at this time.

The following capabilities are available for testing.

1. Publishing Execute reporting-type data to a Snowflake database
2. Publishing Execute reporting-type data to a SQL Server / Azure SQL database
3. Creating Document Synchronizations and Data Selectors against a Snowflake database

Publishing to a Data Warehouse

For BI, reporting and warehousing purposes, Execute now supports publishing all Execute data (documents) to either a client-owned/managed Snowflake database, or a client-owned/managed public-facing SQL Server (Azure SQL) database.

To enable the publishing of Execute data to Snowflake…

1. Create a new empty database in your Snowflake environment
2. Copy plugins_available\integration\product_integrations\warehouse\non_production\snowflake.config to your plugins_available folder or add as a new in-app plugin, and restart Execute.
3. Create a new “Connection String” (Tools > Configuration > Connection Strings) called “Snowflake” with the credentials and information for your Snowflake environment.
4. Run “Tools > Synchronization > Snowflake Schema Publisher” to create tables and helper views in your Snowflake database. This same process would also be run any time you want to update the helper views to include newly created fields in Execute.
5. Run “Tools > Synchronization > Snowflake Document Publisher” to pre-populate your Snowflake database with your existing data (latest version of each non-deleted document). This would typically only ever be run once.
6. Execute will periodically and automatically push incremental updates to Snowflake. You can adjust this timing by changing the “Integration/Snowflake/Snowflake Queue Wait” configuration setting.

To enable the publishing of Execute data to SQL Server/Azure SQL…

1. Create a new empty database in your SQL Server/Azure SQL environment
2. Ensure that the SQL Server / Azure SQL database can be access directly from Execute (no VPNs, etc.)
3. Copy plugins_available\integration\product_integrations\warehouse\non_production\sqlwarehouse.config to your plugins_available folder or add as a new in-app plugin, and restart Execute.
4. Create a new “Connection String” (Tools > Configuration > Connection Strings) called “SQLWarehouse” with the credentials and information for your database.
5. Run “Tools > Synchronization > SQL Warehouse Schema Publisher” to create tables and helper views in your database. This same process would also be run any time you want to update the helper views to include newly created fields in Execute.
6. Run “Tools > Synchronization > SQL Warehouse Document Publisher” to pre-populate your database with your existing data (latest version of each non-deleted document). This would typically only ever be run once.
7. Execute will periodically and automatically push incremental updates to your database. You can adjust this timing by changing the “Integration/SQL Warehouse/SQL Warehouse Queue Wait” configuration setting.

For both Snowflake and SQL Server, the published data is:

1. A table called EXECUTE_DOCUMENTS with up-to-date semi-structured JSON-based representations of all records (documents) in Execute (Wells, AFEs, Users, Accounts, Schedules, Approval Rules, …). If a document is deleted, the corresponding record in this table will not be removed but will have its “deleted” field set to “1” / “TRUE”.
2. (Optional) Helper views which reformat the data from EXECUTE_DOCUMENTS as normal tables (closely resembling the underlying tables in Execute). These helper views are intentionally simplified and do not include deleted records, nor all the complex document versioning tables/fields (_DOC, _DOC_V, _H, …) that made querying the underlying tables complex.

This functionality requires the “OData” module be licensed for your in environment.

Data Selectors and Synchronizations against Snowflake

Execute now supports creating connection strings to Snowflake databases in the Connection String editor. These connection strings can be used by Document Synchronizations and Data Selectors.

I think it’s safe to say that administrators with the new Manage Execute Plugins administrator privilege will be overjoyed that they can now (optionally) manage Execute plugins directly in Execute. This is primarily targeted at Execute SaaS customers, but can be helpful for on-prem installations as well.

NOTE: Plugins found in the plugins folder will continue to work and there is no requirement to migrate some or all of your plugins to in-app managed plugins. If you choose to migrate plugins from the plugins folder to the in-app plugins it is CRITICAL that the migrated plugins in the plugins folder are removed prior to adding them to the in-app plugins list (for SaaS environments, this will require a support ticket). Loading the same plugin twice never yields good results.

Administrators can find the list of in-app managed plugins under Tools > Configuration > Plugins. This screen may look familiar at this point because in-app plugins are treated just like any other record in Execute. They even have change tracking!

Viewing a plugin will show details about the plugin, as well as give the opportunity to edit the “Content” for the plugin.

In addition, we’ve made some improvements to error handling. In most cases, when a plugin fails to load properly, Execute will skip that plugin and continue startup. The “Loaded Successfully” column on the plugins screen will identify any plugins that failed to load (they will also have a red status bar the the left of the plugin row).

It is important to note that plugins managed in this way are included in the database and will get copied as part of the database (for example, when copying PROD to TEST). This can potentially cause some issues where a TEST Execute environment is inadvertently attached to a 3rd-party production system. There are two mechanisms to avoid this:

1. Connection strings and credentials should be stored in Execute’s (new) connection string storage or external credential storage. These values are NEVER copied between environments, and this eliminates the risk of a PROD>TEST migration accidentally causing TEST data to leak into a downstream PROD system.
2. You can tag plugins with a “Plugin Environment” which can limit which environment a plugin is valid for (based on the Environment Label). If unspecified, the plugin will load in any environment. Environment Labels are the little badge next to the “Q” icon (PROD environments are usually blank) »

We hope you are as excited by this functionality as we are. It will hugely streamline the process for managing Execute plugins.

Database connection strings can be managed by an admin with the “Edit External Credentials” privilege under Tools > Configuration > Connection Strings. New connection strings can be defined here and then referenced in your plugin files (rather than embedding database connection strings right in the plugin).

This is now the preferred way to manage database connections made directly from Execute to another system (Integration Agent connections are still managed separately).

• Multiple plugins can refer to the same connection string instead of a separate copy in every file
• The connection strings can be edited without restarting the Execute service (plugin file changes still require a restart)
• Connections can be tested from the UI, rather than having to restart the service and trying to operate the plugin before learning if the connection actually works
• These connection strings still support the @@@ notation for using the separate credential storage feature. It is recommended to use that for passwords, to ensure they are securely stored.

Most plugins that contain a connection string, such as this:

<ConnectionString>account=abc123-abc123;user=secureuser;password=securepassword123;db=EXECUTE;SCHEMA=PUBLIC;WAREHOUSE=COMPUTE_WH</ConnectionString>
<ProviderType>SnowflakeProvider</ProviderType>

Can then be updated to refer to the defined connection string like so. Note: The “ProviderType” is now captured in the connection string and should be removed from the plugin file.

<ConnectionString>Connection List=Server; Id=Snowflake</ConnectionString>
<ProviderType></ProviderType>

If you are migrating a plugin to an in-app managed plugin, you must move the connection string out of the plugin and into the connection string storage.

Please feel free to reach out to Execute Support if you need some help updating your existing plugin files to use this new functionality.

We’ve added the ability to create API Keys to Execute to make it easier/safer to write integrations against the Execute APIs.

1. By default, only admins can create a new API key.
2. Sessions created using an API Key do not consume or require a license.
3. API Keys can be set to expire (user-created API Keys must expire within one year).
4. API Keys work much better in an environment that doesn’t have passwords (i.e., SSO users).

The Problem

Execute has a great set of APIs that many of you use to build integrations between Execute and other systems. Unfortunately, to use these Execute APIs, you needed to create a session using a username and password and the normal login API (used by the app itself). This raises several problems:

1. It Doesn’t work well for environments that use SSO and don’t have passwords.
2. Execute’s normal sessions consume/require a license. This requirement means that integrations start failing when the system is busy because they can’t get a license. It also means that for clients with small numbers of licenses, a long-running integration may lock people out of the system.
3. Execute’s default 2-minute timeout on a session can break long-running integrations.

What is an API Key?

In Execute, an API key is an additional credential that can be used to log into the Execute APIs (or OData) to facilitate integrations. It’s like an additional username and password that are machine-generated (long and secure). Creating a session using an API Key does not consume a license and is more robust than the old-style login.

Creating an API Key

API Keys are managed under Tools > Configuration > API Keys.

It is always a best practice to create unique API Keys for each service/integration to simplify phasing out old credentials or replacing compromised ones.

Admin API Keys

Users with the new Manage API Keys privilege are always able to add new API Keys using the Create API Key button on the top of the API Keys screen.

• A description is always required for an API key and should describe what the key is being used for. A good description might be something like “Integration with Petrosight” or “Data Warehouse”
• You must define when the key expires. Administrators can create API Keys that never expire.
• An admin may also configure the key to impersonate another user. Doing so means that all APIs called using the new API Key will operate as if the impersonated user was calling them. Impersonation is commonly required so an admin can set up an API key for a service account in Execute that they can’t log into directly.

Once created, you need to note the ID and the Key as both are required to use the APIs. The Key will never be shown again. The ID is just the DocumentID for the newly created API Key document and is not a secret.

Non-admin API Keys

By default, non-admin users can NOT create new API Keys. You can permit users to create API Keys by toggling the new Allow non-admin users to create API Keys? setting to “Yes”.

The typical use-case for non-admin self-serve API keys is to support OData use in password-less environments. Alternatively, if only a few users need API Keys, administrators can create API Keys that impersonate that user, and then securely share the Id and Key with the user.

When permitted, users can create a new API Key (for themselves) using the Create API Key button at the top of the API Keys screen.

• A description is always required for an API key and should describe what the key is being used for. A good description might be something like “OData Summary Report” or “Data Warehouse”
• You must define when the key expires. Non-admin users can set a maximum expiry of 1 year.
• Non-admin users can NEVER create API Keys that impersonate other users.

As before, once created, you need to note the ID and the Key as both are required to use the APIs. The Key will never be shown again. The ID is just the DocumentID for the newly created API Key document and is not a secret.

Viewing and Editing API Keys

Current API Keys can be viewed from Tools > Configuration > API Keys.

• Administrative users with Manage API Keys will see all API Keys across all users in the system
• Non-admin users will only see API Keys that they created and those created by other users that impersonate them

Either the owner of an API Key or an admin can change an API Key, but those changes are limited to:

1. Toggle the “Active” flag on an API Key (temporarily enable/disable it)
2. Deleting the API Key
3. Updating the API Key description

Once an API Key is created, there is no way to change the user to impersonate or the expiry time.

Managing API Sessions

When an API Key is in use, administrators will see it under the Manage Sessions screen, where they can terminate it if required.

API Sessions are different

• Only a single active session is permitted for an API key (whereas you can log in multiple times with a username/password)
• API Key sessions timeout after an hour instead of the usual 2 minutes
• API Key sessions do not consume a license

Because of the above, the primary reason to terminate an API Session is if it was accidentally left open and you’d like to terminate it so a new session can be created and any locks it holds can be released.

Using an API Key with Execute

API Keys can be used to call Execute’s APIs, and can also be used for OData.

APIs

Calling any Execute APIs requires you have a valid session.

To create a new Execute session using an API key, call the new /api/Authentication/ApiKey/Login API instead of the previous /api/Authentication/Login API.

The arguments to this API are simply the ID and Key obtained when creating the API Key.

{
  "Id": "a426fcff-6569-4aa6-a596-4dba1469c425",
  "Key": "SK9EwPMwMX4CYKMX6Xc7JMchJp5ZyWEUdAIni5V3OwS6nLfAHZJHrKd8vnruIBnD"
}

The response from the ApiKey/Login call is identical to the normal login call. If the API Key impersonates a user the session will be created as that user.

OData

The new API Keys can also be used to connect to OData for environments/situations where the normal username and password is not appropriate.

When you add custom fields to Execute, they are typically added to a single _CUSTOM table. It turns out that there is a maximum number of columns supported in a table (it varies by database configuration) but it’s roughly around 1000. This can be a problem for organization implementing many RTx-type workflows.

To alleviate this, you can now add additional storage tables in Execute from a document’s configuration page.

In this example, we’re adding a new storage table for fields related to our abandonment process. We could also just call it Custom 2 if we don’t want to separate fields by type.

Once created, new fields can be added to the new table by selecting it as the “Record” when adding a new field.

Something we’ve been asked for a lot ever since Execute was reborn as a web-based application was the ability to stick fields side-by-side on your custom tabs. Here it is!

You configure your custom tabs just as you always have, but now there is a new “Same row as Above” checkbox in your tab configuration, which you can use to indicate that the field should share a row with the field above it. Currently, you can have up to 4 fields share a single row.

Most dates in Execute are actually Date + Time and those come with automatic timezone conversions. Sometimes, however, you just want a plain old date that will always show the same thing regardless of what timezone you are in. For that, we’ve added a new Unzoned Date/Time setting to Date Fields in the Field Configuration screen.

When a date field is set to Unzoned, users will never see a time component for that field, and the value will never be subject to automatic timezone conversion.

For example. In the screenshot below, Date 1 is a normal date field, and Date 2 is a new unzoned date field.

A new setting (inactivateMissingRecords - off by default) was added to synchronizations to automatically inactivate records that are no longer found in the source dataset.

If you would like to enable this in an existing sync, you can add the following to the IDocumentSynchronizer component.

<inactivateMissingRecords>true</inactivateMissingRecords>

Note: Be careful when using this feature as it can/will quickly inactivate records in Execute that are no longer found in the source system. If the source data is a table (populated by a scheduled job such as the replicator) make sure that the table is filled before letting this sync run! As always, it is strongly advised to run this in TEST before doing this in PROD.

See plugins_available\integration\synchronization\synchronize_document_data.config.sample for more documentation.

When creating a new Notification or Reminder, administrators can now use the new “Workflow Task” document type to build custom notifications for workflow tasks which much greater control than was previously available.

These new notification types allow building more complex rules like:

To help get you started, we’ve created a new sample notifications for the Job (RTx) module:

Note: There is currently a known issue that makes it impossible to build notifications when a task activated/reactivated and assigned to a user. We are aware of this and working on a fix in a coming release.

Previously, Execute’s Advanced Workflows allowed administrators to reference fields (either as task-fields or in Blockly rules) from child documents. In practice, these references would rarely work (since the behaviour becomes ambiguous as soon as a parent record has multiple children of the same type) and this functionality has been removed.

Specifically, we have removed:

1. The ability for a Project-level workflow to reference fields on linked Wells or Sites
2. The ability for a Site-level workflow to reference fields on linked Wells or Jobs
3. The ability for a Well-level workflow to reference fields on linked Jobs

As a safety check, Execute 265 and higher will check for these invalid references and, if encountered, will fail to start and the server log will contain a message like this:

2024-05-06 11:17:01.613 [ERR] Exception: System.ApplicationException: Upgrade incomplete. Precondition failed for upgrade of database to version 30: There are 2 task paths that must be addressed. Please contact Execute Support.

If this happens, revert to Execute 21.1.264 and contact Execute Support.

We’ve added some calculated field helper functions to fetch data from tables:

These functions are broken into two parts:

1. Find a row - return the “ID” for the row you’d like to retrieve a value from
2. Retrieve a value - given the “ID” for a row, retrieve the value of a specified field

Find a row functions:

• TableGetRow("TABLE","FIELDPATH","FIELDVALUE") - returns ID of the row where FIELDPATH = FIELDVALUE
• TableGetMinDateRow("TABLE","DATEFIELD") - returns ID of the row with minimum date in DATEFIELD
• TableGetMaxDateRow("TABLE","DATEFIELD") - returns ID of the row with max date in DATEFIELD
• TableGetMinRow("TABLE","NUMFIELD") - returns ID of the row with minimum numeric value in NUMFIELD
• TableGetMaxRow("TABLE","NUMFIELD") - returns ID of the row with maximum numeric value in NUMFIELD

All of the above return the text “MULTIPLE” if there are multiple matched rows.

Retrieve a value functions:

• TableGetText("TABLE","ROW ID","FIELD") - returns the value of a TEXT field
• TableGetDecimal("TABLE","ROW ID","FIELD") - returns the value of a DECIMAL field
• TableGetInteger("TABLE","ROW ID","FIELD") - returns the value of an INTEGER field
• TableGetBoolean("TABLE","ROW ID","FIELD") - returns the value of a BOOLEAN (Yes/No) field
• TableGetDate("TABLE","ROW ID","FIELD") - returns the value of a DATE field

If “MULTIPLE” is passed in as the Row ID, the above functions return Null

Examples:

The following returns the ID of well with DESCRIPTION = “test”

tablegetrow("WELL","DESCRIPTION","test")

The following returns the ID of well with Custom PARNTER name of “Arctic…” (i.e. can peak into fields on document references)

tablegetrow("WELL","CUSTOM/PARTNER/COMNAME","Arctic Canada Ltd.")

The following returns the of the primary well (boolean checking)

tablegetrow("WELL","ISPRIMARY","True")

The following shows how you can chain functions together to get the Company Name value (custom field on the AFE’s Well) from the Primary Well.

tablegettext("WELL", tablegetrow("WELL","ISPRIMARY","True"), "CUSTOM/PARTNER/COMNAME")

In this example, we return the Contract Number for the contract (custom table) with the most recent contract date. (Note: if two contracts share the same latest date, nothing will be returned).

tablegettext("CUSTOM/CONTRACTS", tablegetmaxdaterow("CUSTOM/CONTRACTS","CONTRACT_DATE), "CONTRACT_NUMBER")

If you are using Execute’s Advanced (Task-based) Workflows, to help guide the workflow for an AFE or a Job, it turns out it wasn’t easy to find your way back to the underlying AFE/Job if you wanted to see the whole picture.

In this update, we’ve added helpful little icons in the “My Active Tasks” and “Group Active Tasks” widgets that will bring you directly to the root document.

Similarly, there was no way to open the root document once you were viewing a task (either by clicking the “view” button next to the task in the dashboard, nor by clicking the link in the email), so we added those too.

We’ve added four new formula functions to make it easy to pull text information from linked documents (in the case where there are multiple linked documents):

• DocumentLinkChildrenSum
• DocumentLinkChildrenSumFiltered
• DocumentLinkSum
• DocumentLinkSumFiltered

Each function returns the sum of a numeric field across linked documents.

i.e.

On a site, the following would return the sum of the Cost custom field on linked child wells.

DocumentLinkChildrenSum("WELL","CUSTOM/COST")

While the following would add up the Cost custom field from linked “Maintenance” Jobs for the site.

DocumentLinkChildrenTextFirstFiltered("RTX","CUSTOM/COST","JOB_TYPE/VALUE","Maintenance")

We’ve added four new formula functions to make it easy to pull text information from linked documents (in the case where there are multiple linked documents):

• DocumentLinkTextValueFirst
• DocumentLinkTextValueFirstFiltered
• DocumentLinkChildrenTextFirst
• DocumentLinkChildrenTextFirstFiltered

Each function returns the alphabetically first non-empty value from the referenced field on the linked documents.

i.e.

On a site, the following would return the alphabetically first non-empty Job Description from linked child jobs.

DocumentLinkChildrenTextFirst("RTX","DESCRIPTION")

While the following would do the same, but only for Drilling Jobs.

DocumentLinkChildrenTextFirstFiltered("RTX","DESCRIPTION","JOB_TYPE/VALUE","Drilling")

To improve performance when viewing Change Tracking for documents with a LOOONG history of changes, we have modified the default behaviour to only show/load detailed history for 6o days.

If you’d like to see the full history, there is a handy “Load History” button which will load everything, just as before.

We’ve done our best to make sure it’s clear when you are viewing a partial history (or searching partial history) to avoid any confusion.

Here is how it all looks.

Execute automatically manages System-level document links between…

• An AFE and the Job it was created from
• An AFE and the Project(s) it is linked to
• A Well and it’s Pad (Site)
• A Project and related Wells and Sites
• A Job and related Wells and Sites

If you have some other relationship between records (such as a “Well” drop-down field on an AFE), you can use the new plugins to automatically manage System-level document links based on that field.

This functionality is enabled with the following new plugin configuration files:

• plugins_available/custom_auto_document_link_list.config.sample
• plugins_available/custom_auto_document_link_single.config.sample

The new FormatDate function enables you to convert a date field to text in a specified format (and time-zone).

For example, this formula converts the START_DATE to the America/Edmonton time-zone and then formats it as a long format date/time field (i.e. 2022-12-23 11:30:00 PM).

FormatDate([START_DATE], "yyyy-MM-dd hh:mm:ss tt", "America/Edmonton")

This formula converts the START_DATE to the UTC and then formats it as a date only (i.e. 2022-12-23).

FormatDate([START_DATE], "yyyy-MM-dd", "UTC")

You can find documentation on date format strings here.

The new “notify specific user” block is available when building Notifications and Reminders and allows you to pass in an existing Execute users name, Document ID, or other identifier. When the rule runs, we’ll automatically look up the user’s current email address.

In this update, we have made some HUGE improvements to how we store credentials for 3rd party systems (required for integrations).

What needed to change

Previously, some credentials were stored in the Execute database, while others were embedded in plugins and configuration files.

• Credentials in the database were suboptimal for several reasons:
  • Users with read access to the database could potentially retrieve integration credentials
  • When copying from PROD to TEST you could inadvertently end up with a TEST environment that was integrating with PROD data
• Access to credentials in the plugins and configuration files were typically limited to the IT folks who manage those systems, but it’s still not a best practice to do things that way.

What’s New

With this update, we’ve added a new credential storage mechanism.

• For those of you with on-prem Execute environments, this is an encrypted file called credentials.bin in your service’s config folder. This file is encrypted using the Windows Data Protection API and unusable for any user other than the user running the Execute service. (NOTE: this means that changing the user that runs the Execute service will render all credentials stored in this file unusable!)
• For those of you with Quorum-hosted Execute environments, these credentials are stored securely in an Azure Key Vault.

All external credentials managed from within the Execute UI (Quorum OnDemand Well Operations (WellEz), Peloton, Enersight, and the Integration Agent) are automatically written to the new encrypted credential mechanism.

Relevant plugins and config file now support a sensitive information placeholder element which will refer to credentials stored in the credential store.

What happens on upgrade?

On upgrade, any database-stored credentials (such as WellEz, Peloton, Enersight, and the Integration Agent) will be automatically migrated to the secure credential store. Note that this will come with a change in behaviour as these credentials will no longer copy between Execute environments when you copy the database. While different, we strongly feel this is a much safer behaviour.

Any existing plugins/config files with embedded credentials will be left as-is. If desired, the process of migrating a secret from these files to the credential store is described below.

How do I add protection for credentials in my config and plugin files?

Many plugins (such as synchronizations to external systems) contain sensitive information like database connection strings.

<actual_cost_database>Data Source=SQL_Server;Initial Catalog=SQL_Server;Integrated Security=False;User ID=accounting;Password=hunter2;MultipleActiveResultSets=True</actual_cost_database>

We can replace the password in the connection string with a placeholder label (prefixed with @@@).

<actual_cost_database>Data Source=SQL_Server;Initial Catalog=SQL_Server;Integrated Security=False;User ID=accounting;Password=@@@ACCOUNTING_PASSWORD;MultipleActiveResultSets=True</actual_cost_database>

Then, an administrator with the Edit External Credentials admin privilege can navigate to Tools > Configuration > External Credentials and set the value for that placeholder.

Now, when Execute tries to connect to the accounting database it will evaluate the connection string and replace the placeholder @@@ACCOUNTING_PASSWORD with the password we defined in the External Credentials screen.

Note that for security purposes the password, once added, can never be read from the Execute UI. A best practice is to track integration passwords in a separate secure password management application so that they are available if needed in the future.

The new advanced task-based workflow module in Execute is great and allows you to tightly control the collection of information on your Wells, Sites, Jobs, AFEs, etc.

Up until now, the workflow always marched forward. Once a task was complete, it would stay complete. There was no way to reactivate part of the workflow and force those tasks to be re-run.

<announcer_voice>Until today. . .</announcer_voice>

In this update, we’ve added phase 1 of a new workflow reset feature that allows a task owner or an administrator with the Can Reactivate Workflow Task admin privilege to reactive a task. As part of the workflow definition, administrators can now configure what happens when a task is reactivated, such as:

• Does reactivating a task clear any data (forcing the user to re-enter those fields)?
• Does reactivating a task require the user to manually review/complete the task?
• If a parent task is reactivated, should the child/dependent task also be reactivated?

As mentioned, this is only the beginning.

In this update, task reactivation is a manual process.

Over the coming months, the plan is to introduce an automated aspect to this so that you can build rules like “If the location changes, automatically reset big chunks of the workflow.”

As part of this change, we have also cleaned up the behaviour of the “Manual Completion Behaviour”.

• If a task marked as “Require Manual Completion” has a Completion Rule, that completion rule must be satisfied before the task can be completed.
• If a task is not marked as “Require Manual Completion”, the task must have a Completion Rule to be completed. There is no option for a user to manually complete the task in this case. This is a change from the previous version where the software would incorrectly show a Complete button to the user.
• Tasks where “Require Manual Completion” = yes will show a “Save” and a “Save & Complete” button
• Tasks where “Require Manual Completion” = no will show a “Save” only

We’ve added some new functions to provide more options when building calculated fields against a subset of the data in a table.

• TableMaxDateFiltered - return the maximum date from a filtered subset of the rows in a table
• TableMinDateFiltered - return the minimum date from a filtered subset of the rows in a table
• TableMaxFiltered - return the maximum number from a filtered subset of the rows in a table
• TableMinFiltered - return the minimum number from a filtered subset of the rows in a table
• TableSumFiltered - return the sum of a numeric field on a filtered subset of the rows in a table
• TableCountFiltered - return the count of a filtered subset of the rows in a table

All of the above work like their non-filtered counterparts, but introduce two new parameters:

1. filterPath - is the path to a field on the table row that we are going to use to filter the rows.
2. filterValue - is a text value that we are going to compare to the value of the field in filterPath. The function will only process/include rows where the filterValue is a match to the filterPath value.

For example:

If I have a custom table for tracking Contract details (CUSTOM/CONTRACTS) and I wanted to return the most recent contract date (CUSTOM/CONTRACTS/CONTRACT_DATE) for any “Land”-type contract (CUSTOM/CONTRACTS/CONTRACT_TYPE = “Land”), I would use a formula like this:

TableMaxDateFiltered("CUSTOM/CONTRACTS","CONTRACT_DATE","CONTRACT_TYPE","Land")

(note: the fields above must be enclosed in quotes and not square brackets in this case.)

We will enable both types of authentication by default. They can be turned off by adding one of the following to the <castle> container in user.config.