Complete Execute Release History

This update of Execute changes the version of the .NET Framework Execute uses from .NET Core 3.1 to .NET 6.0.

This should have no user-facing effect on Execute and, because Execute is compiled as a standalone application which includes the appropriate version of the .NET Framework, there is no need to make any changes to the packages deployed on the application server hosting Execute.

Execute will now automatically update its database schema when launching the Execute service against any existing Execute 21 database.

• Because this is an upgrade in place it is imperative that a database backup be taken before upgrading Execute. A failure or interruption during the schema upgrade process may leave the database in an unusable state.
• The release notes for each version of Execute will now explicitly detail any schema changes included in that update.
• Schema updates are forward only. It is not possible to run an older verison of Execute against an upgraded database.
• Environments prior to Execute 21 will still need to use the DatabaseTool to upgrade to Execute 21.
• Environments on any version of Execute 21 will not need to use the DatabaseTool except for migrating Execute from one database platform to another.

For many years, Quorum Execute included major annual releases and small monthly/bi-monthly updates to the current major release. These update releases provided an opportunity to deploy critical bug fixes and minor enhancements to the users of Quorum Execute more quickly.

With Quorum Execute 21 we are moving away from the major annual releases and will focus entirely on providing a stream of small incremental updates to the software (a process we’ve already been doing successfully for years).

The primary reason for this move is to make it easier for everybody to stay current with new developments in Quorum Execute:

• Ensures that users of Quorum Execute have timely access to bug fixes and enhancements.
• For those of you with your own QA process, helps keep the testing burden manageable for each update (testing a few changes rather than a year or two of changes)
• Ensures that critical security fixes are deployed quickly

FAQ

How will I know when new updates are available?

Pending updates will be visible to Quorum Execute administrators in the dashboard, and in the Help > About screen.

How many updates are we talking about?

There is no specific release cadence we are targeting, although we would expect it to be similar to how updates are released today - roughly monthly.

Do I have to take every update?

No, although we do recommend staying current to ensure critical fixes are made in a timely fashion, and to ensure your users always have access to the latest and greatest.

If you choose to skip and update, however, don’t worry. Updating to the current release will always install any updates you missed along the way.

What’s involved in upgrading?

For SaaS deployments of Quorum Execute, get in touch with Client Services to schedule an update at a point where a brief outage is acceptable.

For on-prem deployments of Quorum Execute, simply installing the update over top of your existing deployment will update the software and automatically apply any database updates that are required.

Unfortunately, the 3rd party product AFE Link, which allowed for the electronic exchange of partner AFEs, was discontinued earlier this year.

This release removes support for this defunct product.

• Removal of AFE Link specific administrative privileges
• Removal of AFE Link specific dashboard widgets
• Removal of “Send to Partners” functionality on AFEs

In order to help us make better decisions about future product development, this release incorporates high-level usage telemetry using the industry standard 3rd party service Pendo.

What information is collected?

Under no circumstances is any specific business data (such as AFEs, Jobs, Wells, etc.) collected or transmitted back to Quorum or Pendo. Keyboard activity is never sent to Pendo.

The information we do record is:

• Company Name (Licensed Company)
• User Name
• User Email Address
• Events from user interactions with Quorum Execute (page loads, button clicks, etc.)
• Browser information (remote IP address, User Agent)
• User provided feedback (bug reports / feature requests) (note: this functionality hasn’t been enabled yet)

What will this information be used for?

This information is captured to provide the Quorum Products team critical information to help guide product development.

For example:

• Identify high-usage areas of the software to help prioritize usability improvements.
• Identify unused areas of the software which are no longer needed.
• Sometimes the workflow we think our users will adopt in our software doesn’t match what works best for them. This data will help us identify these situations and better streamline our workflows for you.

This information will not be used for sales or marketing purposes.

What if I’m uncomfortable with this data collection?

Please get in touch with Quorum Execute support.

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.

With Execute’s move to smaller and more frequent releases, keeping tabs on What’s New could be a bit overwhelming. In this release, we’ve changed things a bit.

When new versions of Execute are available, administrators with the “IT Monitor” administrator privilege will continue to see a dashboard widget notifying them of the availability of a new version. This panel now includes a “What’s New” link which shows a summarized list of all new changes (potentially summarizing multiple releases) released since the version currently running in that environment. If you are a few versions behind on your upgrades, this gives one place to look for all of the new bug fixes and exciting enhancements you’ll receive when you upgrade your environment.

Similarly, the “About” screen will also show information about the next available version and a link to the same summarized release notes.

Similarly, under the help menu, release notes have also been split into two options:

1. “Release Notes (Available Version)” is a link to the summarized release notes showing everything new and exciting when you upgrade your environment
2. “Release Notes (Current Version)” is a link to the release notes for the version of Execute currently running in the environment

A new setting Enable "Device Pairing" (default: True) was added to the settings screen to allow an administrator to prevent the pairing of additional devices using the “Device Pairing” feature under the user menu in the top-right of the screen.

This setting is aimed at environments that which to ensure all devices directly authenticate using federated Okta/Azure.

The Quorum Execute Integration Agent is a new service which can be installed on an on-prem server to facilitate integrations between cloud-based deployments of Quorum Execute and on-prem systems. The integration agent is not required for instances of Quorum Execute installed on client-managed infrastructure.

The Integration Agent makes it easier/possible for existing clients to migrate from their on-prem installation of Quorum Execute, to a Quorum-hosted instance, if desired.

More information on the Integration Agent can be found here.

Quorum Execute 2019 introduced first-class integration with Peloton’s WellView and SiteView. This integration allows:

1. AFE Owners can see up-to-date spending against their AFEs (Peloton’s Field Costs)
2. Field staff can see up-to-date AFE status and budget in WellView/SiteView

This release reintroduces that functionality for Peloton’s hosted (SaaS) WellView product.

More information on the integration with WellView and SiteView can be found in the Quorum Execute online documentation.

Grids throughout Quorum Execute have been replaced by a new component that behaves like Excel.

• Grids look and feel much more modern.
• Performance for large grids (many columns or many rows) is substantially faster
• No more pagination. Scroll through large grids with ease.
• After many requests, we finally have support for frozen rows and column headers to make it much easier to work on large grids.

Here is an example from the Capital Budgeting screens:

We all have way too many passwords to manage. IT departments have too many systems to manage (onboarding, offboarding, enforcing policies, etc.).

Quorum Execute has long supported integration with Active Directory for on-prem installations of Quorum Execute. This integration allowed users who were logged into the domain to automatically login to Quorum Execute without needing to set and remember yet another password. It also simplified management for IT groups because some user properties would automatically sync between the domain controller, and Quorum Execute.

In this release, we add optional support for integration with Okta to allow domain federated sign-on for Quorum hosted Quorum Execute environments.

This functionality is configured by the Quorum Application Delivery team (with input from client IT departments). More information is available in the Quorum Execute Documentation.

Those of you using Quorum’s WellEz, or thinking about switching to WellEz, can now integrate your Quorum Execute AFE process and WellEz.

• AFE Owners (in Quorum Execute) - Ensure timely (nightly) access to spending (field costs) for their AFEs. This information helps AFE owners stay on top of their AFEs, more easily identify issues, and take corrective actions (supplementing the AFE, for example) sooner.
• AFE Owners (in Quorum Execute) - When accrual time comes, AFE owners will laugh with glee (or at least be pleasantly surprised) because up-to-date field costs and actuals are collected in one system, making it easy for them to review their accruals, apply adjustments, and submit their accruals, without needing to wrangle data in Excel.
• Field Staff (in WellEz) - Ensure visibility into the latest approved AFE estimate for Jobs in WellEz. This helps field staff ensure that they (a) have an approved AFE before starting work, (b) raise the alarms if field tickets/spending are out of whack with AFE estimates.
• Ensure that WellEz and Quorum Execute users can run Budget v. Spend comparisons in their systems to identify trends and systemic problems estimating AFEs.

Here is a rough workflow diagram describing the interaction between the two systems:

Schedule view configuration is able to control which activities are shown on an operational schedule, how they are colored, what information is shown, which resources are shown, milestones, etc.

Unfortunately, the configuration for a Schedule View is complex. In previous versions of Quorum Execute, this configuration was difficult to modify.

This release includes a new graphical Schedule View Configuration tool.

• It is much easier to use and more discoverable (administrators will be able to use it to make adjustments to their views)
• It avoids syntax issues and typos that you encounter when editing view configuration by hand
• It provides drop-down lists of fields, colors, etc.

Here is a short demo of the new tool:

For those of you whose process when finalizing a project is to revise/supplement an AFE estimate down to match the AFE’s actual spend… we have a new thing!

The new optional “Release Funds” actions make it easy to:

• Supplement an AFE and automatically adjust the AFE estimate to match the actual spend
• Get that new supplement approved (without requiring a complicated approval process)

The new feature is controlled by following new configuration settings.

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.

The new calculated fields in Execute have been phenomenally successful and many of you are finding all sorts of great uses for them. In this release, we’ve added a few new functions based on your feedback.

InList

Sometimes you need to check if a value is one of a big list of options. While you can do this with the if function, it’s not pleasant. Trying to get the brackets right in an expression like if([CUSTOM/AFE_TYPE/VALUE]=="Drilling",true,[CUSTOM/AFE_TYPE/VALUE]=="Complete",true,[CUSTOM/AFE_TYPE/VALUE]=="Drill & Complete",true,false))) is enough to break anybody’s brain.

So… We’ve added the InList function which returns whether a value is found in a list of values.

i.e. the following will return true when the AFE Type is one of “Drilling”, “Completion” or “Drill & Complete”

inlist([CUSTOM/AFE_TYPE/VALUE],"Drilling","Completion","Drill & Complete")

Usually, inList would be used in condition part of if statement:

if(inlist([CUSTOM/AFE_TYPE/VALUE],"Drilling","Completion","Drill & Complete"),"drilling & completion AFE","not a D&C AFE")

FirstNonEmpty

Sometimes it’s helpful to return the first non-empty value from a bunch of text fields (such as when showing the “best available identifier for an AFE”). The new FirstNonEmpty function helps with that!

i.e. Here is a function that returns the description (if one), or the internal justification (if one), or a constant string.

FirstNonEmpty([DESCRIPTION],[INTERNAL_JUSTIFICATION],"This AFE has no name")

Document Link Counting

Another common ask has been around getting a count of linked documents, so we’ve introduced DocumentLinkChildrenCount and DocumentLinkCount to help with that.

i.e. Find the number of child wells for a site.

DoumentLinkChildCount("WELL")

i.e. Find the count of AFEs linked to a Job (child, associated, parent… all are counted).

DoumentLinkCount("AFE")

A common request has been to extend the “AFE - Line-item” and “AFE - Line-item by Date” report types to include some of the additional “approved” and “supplemental” estimate columns found on the base AFE report type.

As such, we’ve extended both report types to include the following additional columns:

• Line-item Detail - Supplemental Gross Estimate
• Line-item Detail - Supplemental Net Estimate
• Line-item Detail - Approved Gross Estimate
• Line-item Detail - Approved Net Estimate
• Line-item Detail - Net Estimate

Added new functions (DocumentLink_____ and DocumentLink____Filtered) to the formula editor to retrieve data from linked documents. These new functions support the following data types:

• Integer
• Decimal
• Text
• Date
• Boolean (Yes/No)

These new functions make it easy, for example, to add a calculated field on the Job that returns the related AFE’s current status or estimate.

Execute now does it’s best to automatically maintain Document Links between related documents. This includes:

• Linking an AFE to the Job it was created from.
• Linking Jobs to the Well or Site they are associated with / created from.
• Linking a Well to the Pad (Site) it is associated with.

These new links are automatically managed by the system and will automatically be updated or removed when you change the underlying field that link is based on. For example: Changing the “Pad” field on the well will automatically update the associated Document Link. These links are identified by a “system managed” badge on the Document Links tab.

These new links are exciting for several reasons:

1. They are bi-directional. From a well you can see the associated sites and click on them to open them. From a site, you see the associated wells.
2. Our new document link formulas make it easy to see/summarize information from linked documents. For example:
   • Show the current AFE Status for the AFE linked to a Job
   • Show the minimum Spud Date for all wells linked to a Site
3. Use the new “Refresh Linked Data” button on the AFE to automatically copy data from linked Wells, Sites and Jobs onto the AFE and the fill out the AFE’s well list.

Document Links are automatically created from this point forward. This update does not retroactively create links on historical documents.

In addition to the AFE process that most of you are using today, Execute also has the ability to track Wells, Sites and Jobs and their associated data and workflow.

For those of you tracking these other details in Execute, we’ve added a new “Refresh Linked Data” button on the AFE that makes it easy to pull information from related Wells, Sites and Jobs onto the AFE.

The first step is to configure the mapping(s) from your Well/Site/Job to your AFE. These are found under Tools > Configuration > Field Mappings.

There are three new Field Mappings which control how attributes are copied onto top-level fields on the AFE.

1. RTX > AFE (mappingId = “update”)
2. WELL > AFE (mappingId = “update”)
3. SITE > AFE (mappingId = “update”)

In addition, there is one new Field Mapping which controls mapping linked wells to new rows in the AFE’s Well List.

1. WELL > AFE (mappingId = “update-well”)

Here is an example mapping that maps three fields from the Well to top-level fields on the AFE. If a single Well is linked to the AFE, pressing the “Refresh Linked Data” button will use this mapping to copy these three values from the well to the AFE.

Next, this feature must be enabled by enabling the Enable 'Refresh Linked Data' on AFEs setting under Tools > Configuration > Settings.

Document Links can be fairly complex and the system will try and follow the links to find all “reasonable” linked documents. This includes:

Jobs:

• Directly linked to AFE

Sites:

• Directly linked to AFE
• Owner of a Job linked to an AFE (Site Job)

Wells:

• Directly linked to an AFE
• Owner of a Job linked to an AFE (Well Job)
• Directly Linked to a Site that is:
  • Directly linked to the AFE
  • Owner of a Job linked to the AFE (Site Job)

Mappings are applied in the following order:

1. Well -> AFE
2. Site -> AFE
3. Job -> AFE

This means that if the AFE is linked to a Well and Site, for example, and both the Well and Site map to the same field, the Site will “win” because it’s processed second.

A mapping will not be applied if multiple documents of that type are linked.

For example, in the following situation the AFE is linked to one Site and two Wells (via. the Site).

• The Well > AFE mapping will not run because the AFE is linked to two Wells
• The Site > AFE mapping will run because the AFE is linked to only one Site
• The Job > AFE mapping will not run because the AFE isn’t linked to any Jobs
• The Well > AFE - Well mapping will run to add each of the two Wells to the AFE’s Well list.

We’ve added two new formula functions to make it easier to extract/report on parts of an AFE’s estimate:

1. GrossEstimateForAccountFilter
2. NetEstimateForAccountFilter

The following example pulls out just a single account’s (9210.247) Net estimate amount.

NetEstimateForAccountFilter("ACCOUNTNUMBER","9210.247")

While this formula sums up the gross estimate for any accounts with a Target Activity Name of “Development”.

GrossEstimateForAccountFilter("CUSTOM/TARGET_ACTIVITY/NAME","Development")

Workflow Tasks in Execute are assigned to a single user through that task’s “Assigned To” rule. In some cases, however, this individual approach is too restrictive. i.e.

• “While Bob is on vacation other members of Bob’s team would like to be able to see and complete tasks assigned to Bob.”
• “A Task needs to be completed by someone in the Land Group (Alice, Bob and Eve) but we don’t care who in particular.”

We’ve introduced a new couple of new settings and a new feature to make this a breeze.

When enabled users who share an eligible* “User Group” with the owner of a task will be allowed to “Take Ownership of Task” and complete the work (using the button they’ll see when viewing the task).

In addition, a new Dashboard Widget (“Group Active Tasks”) makes it easy for Team member to see all the active Tasks that they could participate in.

We’ve been working closely with several of you as you’ve rolled out the new Advanced Workflows and made some changes based on the feedback from that process.

Tooltips

The tooltips on the workflow diagrams weren’t particularly helpful and had an annoying tendancy to get stuck on your screen. We’ve removed them.

Workflow Diagram Box Sizing

Boxes on the workflow diagram now automatically adjust to the size of the task name. This makes it easier to read the diagram and fixes the issue where the task arrows would render incorrectly.

Assigned & Completion Date on Workflow Diagrams

We’ve added the Assigned and Completion date fields to the workflow diagram.

Subworkflow Visualization

If your workflows make use of Subworkflows, we’ve made some huge improvements.

1. Only the main workflows are listed on the Workflows tab on your Well/Site/Job. This makes it much less confusing for end-users.
2. Active subworkflows show in a panel on the main workflow (see screenshot below), making it much easier to see what’s going on and how the subworkflow relates to the main workflow.
3. Clicking on a subworkflow task will always bring you to the detailed diagram and task status page for that subworkflow.
4. Main workflows tasks and subworkflow tasks are shown together in the task list under the main workflow making it much easier for those involved in the workflow to find their tasks.

We’ve added some cool new functions to the formula language used for calculated fields and calculated report columns. These include functions for dealing with table data (Min/Max/Count), and linked documents.

Table Functions

The following new functions make it possible to summarize table data from a formula.

• TableMinDate/TableMaxDate - return min/max of a date column in a table
• TableMin/TableMax - return min/max of a numeric column in a table
• TableSum - return sum of a numeric column in a table
• TableCount - return row count of a table

If, for example, we have a table like this:

We can build a formula to retrieve the maximum depth with this formula:

TableMax("CUSTOM/GEOPROG","EST_TD")

Or we can return the number of GeoProg rows with:

TableCount("CUSTOM/GEOPROG")

Document Link Functions

Document Links are a great way of linking records in Execute (such as linking Jobs and AFEs together). We’ve added new functions that allow navigating these links from a formula to make it easy to fetch related information from another document in the system.

The new functions added are:

• DocumentLinkChildrenMinDate/DocumentLinkChildrenMaxDate - return min/max of a date field on linked documents of a certain type
• DocumentLinkChildrenMinDateFiltered/DocumentLinkChildrenMaxDateFiltered - same as above with filtering on a single column
• DocumentLinkTextValueFiltered - return a single text value from a linked document meeting a single column filter
• DocumentLinkDateValueFiltered - return a single date value from a linked document meeting a single column filter

Here I have a document linked to three Jobs (2 drilling and 1 completion):

We can build a formula that will retrieve the first (minimum) Spud date from linked Drilling Jobs with:

DocumentLinkChildrenMinDateFiltered("RTX","CUSTOM/SPUD_DATE","RTX_TYPE/DESCRIPTION","Drilling")

Or we could build a formula to retrieve the pad construction date from the linked Construction job with:

DocumentLinkDateValueFiltered("RTX","CUSTOM/CONSTRUCTION_DATE","RTX_TYPE/DESCRIPTION","Pad Construction")

Since Quorum Execute has joined the Quorum family, we thought it was a great time to refresh our look a bit.

Quorum Execute 21 now features a Quorum inspired color schema.

We love the new look and hope you do too.

If, however, you long for the old color schema you are can select it under your user settings screen.

It’s always important to keep software up-to-date and take advantage of any/all security fixes.

In this release, we have updated the versions of some of the 3rd party libraries that we use within Quorum Execute. This includes:

• jQuery
• jQuery UI
• Bootstrap
• MomentJS
• UnderscoreJS

In addition, we have migrated from our older charting library (HighCharts) to eCharts.

All of the above updates are behind the scenes and should have no impact on the end-users.

The new Bulk Forecast update utility makes it easier to update capital forecasts across many projects via. Excel. It will extract current forecast data (for a user-specified date range and set of projects) and export that to Excel as a starting point for the update. The user can then see the current forecast, quickly make bulk updates across many projects in Excel, and then re-upload those changes into Quorum Execute.

A common problem for operators who combine multiple phases of a project into a single AFE (such as a combined Drill & Complete) is getting visibility into specific phases of the estimate from reports, etc.

The new GrossEstimateForAccountGroup and NetEstimateForAccountGroup formula functions make it easy to extract parts of your AFE’s estimate for reporting.

During some code reworking as part of a bug fix in Execute 21.1.184, a critical error was unfortunately introduced that caused issues with the handling of the selected operator on AFEs.

When an AFE was updated, the code was incorrectly updating the Operator field to the selected Parent Company for the AFE.

On operated AFEs where the Operator and Parent Company were the same, there would be no effect caused by this issue. Unfortunately for non-op AFEs or affiliate operated AFEs, this would cause the operator to be incorrectly changed.

This issue was present in both Execute 21.1.184 and 21.1.188 and would affect any AFEs created or updated by that version of the software. Historical AFEs that were not edited with either of the two affected versions of the software will be unaffected.

Fortunately, Execute’s extensive change history means that this data was not lost.

If only a small number of AFEs were effected, it might be that manually updating them is the quickest path forward. For larger numbers of AFEs get in touch with Execute Support and we can work with you to create a script to fix up any affected AFEs.

Details on the Issue and Resolution

The change was a copy-paste mistake that unfortunately slipped through our development code review, normal QA process, and our automated QA process.

The code read:

editableRecord.SetField(Paths.AFE.OPERATING_COMPANY, currentDocumentData.ReadDocumentField(Paths.AFE.PARENT_COMPANY));

instead of:

editableRecord.SetField(Paths.AFE.OPERATING_COMPANY, currentDocumentData.ReadDocumentField(Paths.AFE.OPERATING_COMPANY));

A mistake that, in retrospect, is very easy to spot, but we missed seeing it amidst the larger set of changes.

In this release, we have fixed the offending code, but also re-reviewed the entire larger change to make sure no other similar errors were introduced. From what we can see this was the only issue.

To help avoid mistakes like this, we do employ and continue to invest in a suite of automated tests which are run as part of every build. Unfortunately, our automated build scripts only tested operated AFEs where the operator and parent company were the same company, so they didn’t catch this mistake. Our automated test development team is extending our testing model to include other operator combinations to make sure mistakes like this can’t happen in the future.

Our sincere apologies for any trouble this has caused. Please do reach out if you have any further questions or concerns.