Hi,

The column-selection dropdown is not part of Global Search — it belongs to the crt.SearchFilter ("Search") component on Freedom UI list pages. Real Global Search (the shell header box → GlobalSearchResultPage) has no column selector at all, only a section filter, and nothing configurable changes that. There is no supported switch (feature, system setting, or designer property) that pins the list search to one column or hides the selector — but it can be done declaratively in the page schema, no custom handler needed.

Recommended customization (Creatio 8.3.4+ / 10.x)

In the list page schema (Freedom UI Designer → source code, or the package schema), e.g. Contacts_ListPage / your Usr…_ListPage. Example pins search to Email:

viewConfigDiff — merge into the existing element:

{
  "operation": "merge",
  "name": "SearchFilter",
  "values": {
    "columnsGroupsConfig": { "columnsGroups": [] },
    "_filterOptions": {
      "expose": [{
        "attribute": "SearchFilter_Items",
        "converters": [{ "converter": "crt.SearchFilterAttributeConverter", "args": ["Items"] }]
      }],
      "from": ["SearchFilter_SearchValue", "SearchFilter_FixedColumnsGroups"]
    }
  }
}

viewModelConfigDiff (or viewModelConfig.attributes if the schema uses that form — they are mutually exclusive):

{
  "operation": "merge",
  "path": ["attributes"],
  "values": {
    "SearchFilter_FixedColumnsGroups": {
      "value": [{
        "group":   { "name": "Items", "caption": "Items" },
        "columns": [{ "name": "Email", "caption": "Email" }]
      }]
    }
  }
}

Why it works: a truthy columnsGroupsConfig in the schema makes the preprocessor skip its own binding; with zero columns showColumnsGroups is false, so the icon is never rendered and the component/handler paths tolerate empty groups. The exposed SearchFilter_Items attribute now derives from the constant groups, so every search builds a filter over exactly Email, and the Items data source reloads (loadOnChange). Creatio itself ships a literal columnsGroupsConfig on ConfActivityLog_ListPage, so the pattern is supported metadata, not a hack.

Gotchas (each verified):

• Use exactly {"columnsGroups": []} — an empty {} throws in showColumnsGroups.
• group.name must equal the converter arg / grid items attribute (Items on standard section pages; on other pages check the page's existing _filterOptions, e.g. AddressList). A wrong group name silently disables filtering; a wrong column name yields zero rows.
• Column must be a text/lookup/numeric column of the entity; it does not need to be displayed in the grid.
• Every attribute listed in from must exist, otherwise SearchFilter_Items never emits.

8.3.0 (and earlier 8.x): the preprocessor overwrites columnsGroupsConfig unconditionally unless the schema also defines valueChange. Add to the same merge:

"valueChange": {
  "request": "crt.SearchFilterColumnsGroupsRequest",
  "params": {
    "value": "@event.value",
    "searchFilterColumnsGroups": "@event.columnsGroups",
    "searchFilterGroups": [{ "filterAttributeName": "SearchFilter_Items", "viewAttributeName": "Items" }],
    "searchValueAttributeName": "SearchFilter_SearchValue",
    "searchFilteredColumnAttributeName": "SearchFilter_SearchFilteredColumn",
    "searchFilteredColumnsGroupsAttributeName": "SearchFilter_FilteredColumnsGroups"
  }
}

Lighter alternative if hiding isn't required: keep the default _filterOptions and set a literal columnsGroupsConfig with one group/one column (+ "primaryColumnName": "Email"). The icon stays, but the menu offers only that column (the "All" option needs >1 column).

If you really mean Elasticsearch Global Search

No per-query column choice exists anywhere in the stack (GlobalSearchService.Search(queryString, sectionEntityName, …)). The only column-level control is the GlobalSearchIndexedDataConfig system setting (exclude schemas/columns from indexing; needs re-indexing) plus relevance settings GlobalSearchDefaultEntityWeight, GlobalSearchDefaultPrimaryColumnWeight, UseInexactGlobalSearch, GlobalSearchShouldMatchPercent (Global search). Restricting it to one column would mean excluding every other column from the index — technically possible, not a UI option.

Short answer: yes, the pattern you posted is valid, and it is essentially the same approach the platform core uses internally. It should not cause intermittent issues on MSSQL or PostgreSQL. A few clarifications and recommendations below.

1. SystemUserConnection returns a shared instance, not a new one per call.
Your reading of the decompiled code is slightly off here. With default settings, AppConnection.SystemUserConnection lazily creates a single SystemUserConnection and returns that same object on every access. So all your parallel branches are working with one connection object.

2. That is fine, because SystemUserConnection is designed for concurrent use.
The class overrides how it obtains a DBExecutor. When the database engine does not use MARS (which is the default for both MSSQL and PostgreSQL in Creatio), the executor is cached per managed thread. Each Parallel.ForEach worker therefore gets its own DBExecutor and its own database connection, and Entity.Save starts and commits its transaction on that thread's executor only. The connection's internal caches are thread-safe collections. The core itself runs Parallel.ForEach loops that create entities on the shared SystemUserConnection, fetch them, and save them, exactly as your script task does.

3. Where the "not thread-safe" warning comes from.
It applies to a regular UserConnection, such as the one your script task is executing under. For a regular connection, the executor lookup will reuse any executor that currently has an open transaction, regardless of which thread owns it. Two threads calling Entity.Save on the same regular UserConnection can end up on the same executor mid-transaction. So the rule is: inside the parallel body, use only the system user connection, and never touch the process's own UserConnection from the worker threads. Your code already follows this.

4. Recommendations.

• Keep using Terrasoft.Core.Tasks.Parallel rather than System.Threading.Tasks.Parallel. The Creatio wrapper initialises and resets the platform's logical call context for each branch, which you already have.
• Keep creating Entity, Select, and EntitySchemaQuery objects inside the loop body, one per iteration. Do not share them between branches. Again, your code is already correct here.
• Each worker holds a database connection while its batch runs. Keep MaxDegreeOfParallelism modest and well below the connection pool size, since regular user requests share the same pool.
• Exceptions thrown inside branches are returned as an AggregateException from ForEach. Wrap the call if you want to log individual batch failures instead of failing the whole process.
• Optionally, resolve appConnection.SystemUserConnection once before the loop and capture it. It makes no functional difference since the same instance is returned, but it reads more clearly.

5. On the background operations documentation.
You are right that Task.StartNewWithUserConnection is fire-and-forget and does not let the caller wait for completion. For a case where the launching code needs to know when all work is finished, Terrasoft.Core.Tasks.Parallel.ForEach with the system user connection, as you have it, is an appropriate choice.

Thanks Oleg, very useful to have this information. Is there any way of safely using a non-System User Connection inside patterns such as the Parallel.ForEach so that any data changes appear as being performed by the instigating user, or is that not possible? I don't need it for this use case, but it's definitely something I've thought about in the past.

Harvey Adcock,

Good question. Yes, it is possible, and there are two ways to do it depending on how far "appears as being performed by the instigating user" needs to go.

Option 1: keep the system connection, set the audit columns explicitly.
If all you need is for ModifiedBy (and CreatedBy for inserts) to show the real user, you do not need a user connection at all. Entity.Save only fills the history columns when they have not been explicitly changed to a non-null value. So this works with your existing pattern:

var initiatorContactId = UserConnection.CurrentUser.ContactId; // captured before the loop

// inside the parallel body, on the system connection
contact.SetColumnValue("UsrColumnName", customer.columnNameValue);
contact.SetColumnValue("ModifiedById", initiatorContactId);
contact.Save(false);

This is the simplest and cheapest approach. Its limitation is that everything else still runs as the system user: access-rights checks, default record rights on inserts, and anything downstream that reads UserConnection.CurrentUser (business processes, event listeners, change log) will see Supervisor.

Option 2: one dedicated UserConnection per worker, logged in as the instigating user.
If you need the work to genuinely run in that user's context, create a separate connection per parallel branch. This is public API and is what the platform's own background-task infrastructure does internally:

string userName = UserConnection.CurrentUser.Name;
TimeZoneInfo timeZone = UserConnection.CurrentUser.TimeZone;
var appConnection = UserConnection.AppConnection;

Terrasoft.Core.Tasks.Parallel.ForEach(batches, options, batch => {
	var uc = new UserConnection(appConnection) {
		SessionId = Guid.NewGuid().ToString()
	};
	try {
		uc.Initialize();
		uc.Login(userName, timeZone, needRegisterSessionStart: false);
		foreach (var customer in batch) {
			var contact = uc.EntitySchemaManager.GetInstanceByName("Contact").CreateEntity(uc);
			if (contact.FetchFromDB(customer.customerId)) {
				contact.SetColumnValue("UsrColumnName", customer.columnNameValue);
				contact.Save(false);
			}
		}
	} finally {
		uc.Close(SessionEndMethod.Logout, needRegisterSessionEnd: false);
	}
});

Notes on this approach:

• One connection per branch, not per record. Login reads the user's profile, culture and settings from the database and runs a licence check, so it is not free. Your batching already gives you one branch per batch, which is the right granularity.
• The user must be active and licensed, otherwise Login throws. That is the same rule as for an interactive login.
• Access rights are enforced for that user, which is usually what you want in this scenario, but it means saves can fail where the system connection would have succeeded.
• needRegisterSessionStart: false and needRegisterSessionEnd: false stop the connection from appearing as a separate login in the user session log. Drop them if you want those sessions recorded.
• Always close the connection in a finally block. Each one owns its own database executor and connection, and Close also clears its session-level caches.
• Keep parallelism modest. Each branch holds a database connection from the shared pool for the duration of its batch.
• The single-argument Login overload performs no password check. It is intended for trusted server-side code that has already authenticated the user, so never feed it a user name that comes from client input.

What not to do. Do not pass the process's own UserConnection into the worker threads. A regular UserConnection reuses any database executor that currently has an open transaction, regardless of which thread started it, so two parallel Entity.Save calls can end up interleaved on one executor. That is the real source of the "not thread-safe" warnings you found. A connection that is created and used by a single worker thread does not have this problem.

In short: for audit columns alone, set ModifiedById on the system connection. For true user context, create a fresh UserConnection per branch and close it when done.

Hi,

A business process only writes data. It cannot change color or font weight on the page. But the page can change its own styling based on data, so the pattern is: the process writes a "mismatch" flag, and the page reads that flag to style the field.

Step 1. Store the comparison result in a column

On the object shown on the page, add one column per compared field, for example UsrDobMismatch (Boolean). Optionally add a text column UsrDobColor that holds either auto or a hex color like #d32f2f.

The business process reads the four records (Read data x4), compares them with a Formula element, and writes the result with Modify data. Trigger it on record save or on a schedule, whatever fits your flow.

Step 2. Style the page from that column

Option A, no code at all. In the Freedom UI page designer, add two copies of the value element for each field. Make one plain and one bold with red color (the Label element has color and thickness settings in the designer). Then add page business rules: show the red element when UsrDobMismatch is true, show the plain one when it is false.

Option B, small code change. Show the value as a crt.Label instead of an input and bind the styling properties to attributes. Label properties support $Attribute binding, so if the process fills the color column, no handler is needed:

{
  operation: "insert",
  name: "SurveyDobLabel",
  values: {
    type: "crt.Label",
    caption: "$PDS_UsrSurveyDob",
    labelType: "body",
    labelColor: "$PDS_UsrDobColor",        // "auto" or "#d32f2f"
    labelThickness: "$PDS_UsrDobThickness" // "default" or "semibold"
  },
  parentName: "SurveyColumn",
  propertyName: "items",
  index: 1
}

If you prefer not to store styling values in the database, keep only the Boolean column and compute the color in a crt.HandleViewModelAttributeChangeRequest handler on the page. When the Boolean attribute changes, set a DobColor attribute to red or auto and bind labelColor to it.

One thing to watch: if the process runs after save, the page will show the new styling only after reload. If the users expect it instantly, do the comparison in the page handler instead of the process. The four values are already loaded on the page, so the handler can compare them directly and set the color attributes with no round trip.