Changes since Execute 21.1.276

In many places throughout Execute, information from linked documents can now be included without requiring you to build calculated fields, etc. The examples below are primarily around Wells, Jobs and Pads but the functionality is available across any for any record type in Execute.

Browse Reports (User Facing)

Using our new column picker, everyone can now build reports that include/reference data from related documents.

Here is a quick example showing how to include Well and Pad-level fields on a Job report.

We always strive to minimize non-admin/end-user-facing changes to avoid the need to retrain users. In this case, while there is a visible change for the end-user, we hope the change is small and obvious enough that it won’t cause any confusion.

Custom Tabs

Administrators can also include fields from related documents when building custom tabs. For example, a Job custom tab can include fields from the linked Well or Pad for reference.

Note that currently, these referenced fields are NOT editable (i.e. you can’t edit a Well field from the Job), but we’re working on that!

Workflow Tasks

Administrators can include fields from related documents on workflow tasks. For example, a Job-level workflow task can include fields from the Job, the Job’s Well, and the Job’s Well’s Pad! Unlikely Custom Tabs, these fields are all editable (assuming the user has the appropriate permissions).

Custom Business Rules (Blockly)

And, finally, you can do this when building custom business rules using Blockly too!

Execute used to offer similar functionality for specific references using our “Reference Fields” dropdowns. These fields have been replaced by the new (more capable) functionality, and any existing rules using the old Reference Fields should have been automatically updated to the new structure*.

Note: The old Reference Fields did allow building some references which we consider problematic because their behaviour was unpredictable. We have removed support for these problematic relationship types. Existing rules will continue to work as they did before, but it will no longer be possible to create new rules of these types.

The following relationships are no longer supported.

1. Project > Well
2. Project > Site
3. Site > Well
4. Well > Job
5. Site > Job

For clarity, the way to read an entry like “Well > Job” in the above list is that it is not valid for a Well-level report, workflow task, report, etc., to refer to a Job-level field. The reason is that a Well often contains more than one Job, and as soon as more than one Job is referenced, it is impossible to show a single value for a linked Job-level field. Previously, we allowed rules to be built like this, but they would silently stop working as soon as more than one Job was linked.

Execute’s Data Warehousing feature has received many updates:

SQL Warehouse

1. We have removed the NORMAL and MATERIALIZED options for the creation of helper views since they were not-performant with larger datasets. We added a new option TABLES_AUTO (the new default, and our recommendation for most cases) which will similarly ensure that the helper tables are kept current automatically.
2. We have added support for breaking very large documents (typically only seen with Schedules) into smaller chunks. To enable this, the EXECUTE_DOCUMENTS table has a new chunk column. If you are querying EXECUTE_DOCUMENTS directly, you may need to adjust your queries to handle this correctly (When querying normal fields, filter to chunk=0. When querying child tables, include data from all chunks). If you are querying our automatically created helper tables, this work has been done for you.
3. To avoid issues where restarting Execute could take a very long time, Execute will no longer wait for a sync to finish on shutdown but, instead, keep a highwater mark of successfully sync’d records. After restart, and on the next automated sync, Execute will publish any records modified since that stored highwater mark.
4. Fixed behavior when Deleting and Undeleting records.
5. To avoid excessive replication of data, the EXECUTE_DOCUMENTS_LATEST table no longer includes the data from the latest records. Queries relying on this table will need to join on EXECUTE_DOCUMENTS.

Snowflake

1. We have added support for breaking very large documents (typically only seen with Schedules) into smaller chunks. To enable this, the EXECUTE_DOCUMENTS table has a new chunk column. If you are querying EXECUTE_DOCUMENTS directly, you may need to adjust your queries to handle this correctly. If you are querying our automatically created helper tables, this work has been done for you.
2. To avoid issues where restarting Execute could take a very long time, Execute will no longer wait for a sync to finish on shutdown but, instead, keep a highwater mark of successfully sync’d records. After restart, and on the next automated sync, Execute will publish any records modified since that stored highwater mark.
3. Fixed behavior when Deleting and Undeleting records.

Mandatory Manual Upgrade Step

Because of the changes made in this update, administrators must manually perform the following steps after upgrading Execute.

1. Replace your SQL Warehouse or Snowflake plugin with the latest version from plugins_available
2. Verify that the Create Views setting is set appropriately (for SQL Server, we strongly recommend TABLES_AUTO)
3. Remove all Execute created objects in Execute’s Data Warehouse schema (EXECUTE_DOCUMENTS, AFE, PROCESS_EXECUTE_DOCUMENTS, ...).
4. Run the Schema Publisher synchronization task.
5. Run the Document Publisher synchronization task.

Execute will now correctly prevent passwords from being used in environments configured to use Single Sign-on. This change has the potential to prevent users from accessing these SSO environments if they were relying on a username and password instead of the SSO mechanism.

This affects environments…

1. using OKTA or OIDC for SSO
2. using our legacy Windows login mechanism where the Authentication Type setting is set to WINDOWS

This means that:

1. Users will not be able to login with a user-specified password in these environments.

• Login screen
• APIs
• OData

2. Users will not be able to set a password. The password changing feature will be hidden from the user’s profile.
3. Administrators will not be able to set a user’s password from the user management screen.

Any integrations using Execute’s API or OData should transition to using Execute’s safer API Key mechanism.

If you require the use of user-specified passwords in your SSO environment (NOT RECOMMENDED), you can override this new behavior by setting the new Allow User Passwords When Federated setting.