Hi,

Why you don't see the button

• One data source per page. The guide says "Each mobile page works with a single data source." In your screenshot, the VERIFICATION group in the Components panel is that data source. Its fields appear under Data model attributes (A. Age, A. CIF No, and so on).
• The button is only for pages that don't have one yet. You get Add data source → New data source (then Name and Description) when you create a mobile page from a template that has no data source. Creatio then creates a new object and connects it to the page. Your form page was created from the existing app, so it was bound to the Verification object automatically.
• Version. This designer feature needs Creatio 8.3.2 or later. If you're on an older version, the button won't be there at all.

What you can do instead

1. Add fields to the current data source. In the VERIFICATION group, use the Add new field tiles (Text, Number, Dropdown, …) or drag existing attributes from Data model attributes onto the page.
2. Show data from another object. Mobile pages share data sources with their desktop Freedom UI pages: "data sources configured for a Freedom UI page are automatically available on the corresponding Freedom UI mobile page." Open the desktop Verification form page in the Freedom UI Designer, add the extra data source there (for example, a list or detail of related records), save it, then reopen the mobile designer.
3. Use a separate object as the main source. Create a new mobile page from a template. That's where Add data source appears.

Also note that the Academy page recommends the Freedom UI Mobile Designer only for newly created apps, not for adding mobile pages to apps that already existed. If "Mobile Survey" is an older app, that may explain other limitations you run into.

Hi,

The live data update checkbox is already on, so the problem is usually that this page is not connected to that object's updates, or the way the process writes the value doesn't send a refresh. Since it works on your other pages, compare MyApplication against a working page on each point below.

1. Is MyApplication a Freedom UI page?

Live data update only works on Freedom UI pages. If MyApplication is a Classic UI page, or the section opens the record in a classic page, the checkbox does nothing. Then you either rebuild the page in Freedom UI or add code to refresh it (a client message plus a page reload).
Check: open the page in the designer. A Freedom UI page uses the drag-and-drop designer with components on the left.

2. Is the checkbox on the right object?

The setting only matters on the object that is the page's primary data source. Common mismatches:

• The page is based on a different object, such as a replacement or a similarly named object (for example UsrMyApplication versus UsrApplication).
• Field ABC belongs to a related object (for example Contact.ABC shown through a lookup), and the process updates that related record. Then the related object needs live data update enabled too.
• The process updates a different object from the one the page is showing.

Check: in the page designer, look at the data source and its object name. Compare it with the object in the process's Modify data element.

3. Was the object saved and published after you ticked the box?

Ticking the box is not enough. You need to Save and Publish the object. Then log out and back in, or clear the browser cache, so the page loads the new setting.

4. How does the process write ABC?

• Modify data element: sends the update to open pages. ✅

• Script task that writes with direct SQL (Update, CustomQuery, a raw UPDATE ...): skips the object layer, so no update is sent to the page. ❌

  If you need a script, save through an Entity instead, for example entity.SetColumnValue(...) followed by entity.Save().

5. Signal timing

If the signal fires on Record modified and the user saves from the same page, the process can write ABC while the page is still finishing its own save. The page then keeps the old value it has in memory.

• In the signal element, make sure "Run following elements in background" is ticked so the calculation runs after the save completes.
• If the user still has unsaved changes on the page, the incoming value may not overwrite the form. Test with a clean, saved record.

6. Is ABC a real field on the page?

ABC must be bound to the object's column through the page's data source. If it is a page attribute or a custom field filled by a handler, live update won't refresh it.

The first thing to check is publishing and compiling the object, then performing the test after compilation is complete.

Quick test to narrow it down: open a MyApplication record in one browser tab. In another tab, open the same record in the section list, or as a different user, and change ABC by hand.

• If the first tab doesn't update, the cause is points 1 to 3 (page or object setup).
• If it does update but the process change doesn't show, the cause is points 4 or 5 (how or when the process writes the value).

Hi Oleg, so I already tried to open Form Page with another browser, and login with another account. Then I changed the value from ABC field in that another browser.

• In another browser = Saved--> In the first browser = the value is not change
• In another browser = Not saved (only change value) --> In the first browser = the value is not change also

Based on your suspect above, so maybe the cause is points 1 to 3.
I checked from point 1 to 3 :
1. My Form Page is using Freedom UI

2. Yes, it is in the right object. I compare ABC field in the form page (it is from primary data source)

3. Yes, the object I already Save & Published after tick the box "Enable Live Data Update"

So, all is correct setup Oleg, any suggestion? Thank you for help.

Dedi Sadikin,

Just to be on the same page: have you tried compiling the object using this option?

It might help, we had tickets related to such behavior in the past and the fix was to compile the object.

Your test shows the problem isn't the business process. A manual change saved from another browser also doesn't reach the first browser, so live update isn't working for this page at all.

The "not saved" case is normal: unsaved changes never go to other users. Only the "saved" case matters.

Step 1: Repeat the test on a page that works

Do the same two-browser test on one of the pages where you said it works. Use two different users, change the field, save, and watch the other browser.

• If that page also doesn't update: the problem is server or network, not your object. Common causes:

  • The WebSocket connection is blocked by a proxy, load balancer or firewall.
  • Several web servers run without Redis message sharing configured. A save on server A is then never sent to a user connected to server B, so it looks random by page or user.

  To check, open the browser DevTools (F12), go to Network, and filter by WS. There should be an open WebSocket connection, and a message should arrive when the other browser saves. If nothing arrives, give this to your Creatio admin or hosting support.

• If that page does update: the problem is specific to the Application object or the MyApplication page. Continue with step 2.

Step 2: Check the object and page

1. The checkbox stayed ticked. Close the object designer, reopen the Application object, and confirm "Enable live data update" is still ticked. If the object has a replacing version in another package, the tick may have been saved somewhere that isn't used.
2. Clean restart. After publishing, the setting may still be cached. Log out every test user and clear the browser cache. On-site, restart the app or ask your admin to flush Redis. On cloud, ask support to restart the site.
3. No unsaved changes in the first browser. If you edited anything on the page in browser 1 before the other save, the page may keep its own values. Open the record fresh and touch nothing, then save in browser 2.
4. Custom code on the page. If MyApplication has handlers added by a developer, temporarily disable them and test again. Look in the page's source code at handlers, especially anything that intercepts data loading or attribute changes.
5. Isolation test. Create a new Freedom UI page for the same Application object using the default template, add field ABC, and run the two-browser test.
   
   • It works: the original MyApplication page is the problem. Compare the two, or rebuild the page.
   • It doesn't work: the object is the problem. Raise a ticket with Creatio support and include your Creatio version and this test.

If you need a fix now

Until live update works, add a Refresh button to the page. In the Freedom UI button properties, choose the action that reloads the page data. Users can then see the process result without a full browser refresh.

Your Modify data setup in the screenshot looks correct: the object is Application, the filter is Id = the signal's record, and it sets Monthly Installment. Once live update works for manual edits, the process result should show up as well.

Oleg, thank you for the feedback, but is it possible if we have session, maybe 15 minutes on zoom? I hard to explain in this Community. I don't know, I think we have missunderstanding. Thank you, appreciate it.

Dedi Sadikin,

Please register a ticket by emailing us at support@creatio.com, specifying link to the application where the issue occurs with external access to this application (access to data and configuration are needed) under the system administrator and steps to reproduce the issue and the support team will look into it.

Hi Oleg, thank you for the feedback, I already email to support creatio about this, and I upload video how to produce this question, also I already give access until 14 Oct 2026. Thank you for the support Oleg, appreciate it.

Hi,

You can do this in a business process with no code. Process formulas in Creatio are compiled as C# expressions, so you can use Math.Pow inside a formula field even though the formula editor has no "power" button.

Process layout

[Signal: record added / modified (fields P, B, n)]
        ↓
[Read data: the record]
        ↓
[Formula: i]  →  [Formula: Pow]  →  [Formula: A]
        ↓
[Modify data: set field A]

1. Start signal

• Use an Object signal on your object, triggered by "Record added" or "Record modified".
• For "modified", tick only the fields P, B, n. If you leave A ticked, writing A starts the process again and it loops.
• You can use a button on the page that runs the process instead.

2. Read data

Read the record by Id = Signal.Unique record Id.

3. Process parameters

Add three Decimal parameters: i, Pow, Result. Fill each one with a Formula element:

i

[#Read data.First item of resulting collection.B#] / 100m / 12m

Write 100m / 12m (decimal literals). If B is an Integer field, B / 100 does integer division and gives 0.

Pow = (1 + i)ⁿ

Convert.ToDecimal(Math.Pow(Convert.ToDouble(1 + [#i#]), Convert.ToDouble([#Read data.First item of resulting collection.n#])))

Math.Pow works with double and Creatio fields are decimal, so the formula converts to double and back.

Result = A

[#i#] == 0 
  ? [#Read data.First item of resulting collection.P#] / [#Read data.First item of resulting collection.n#]
  : Math.Round([#Read data.First item of resulting collection.P#] * [#i#] * [#Pow#] / ([#Pow#] - 1), 2)

The i == 0 branch covers a 0% rate (B = 0). Without it the formula divides by zero, because the payment is then just P / n.

4. Modify data

Update the same record (Id = Signal.Unique record Id) and set A = [#Result#].

Notes

• One formula is possible. You can put the whole calculation into one formula inside Modify data, but three separate parameters are much easier to debug: you can see each value in the process log.
• Check the result. With P = 10 000, B = 12, n = 12, you should get A ≈ 888.49.
• Live value on the page. The process runs after the record is saved, so A appears only after save and refresh. If you need A to update while the user types, a business process won't do that; you'd need a page handler, which means code.

Oleg Drobina,

Thank you Oleg, appreciate it for the feedback

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.

Hi,

I found, enable the feature "EnableDateTimeCalendarListPickerView"..

1. Open the Feature toggling page
   Enter {CreatioURL}/0/Flags in the browser address bar, for example https://mycreatio.com/0/Flags. This is valid for Creatio 8.x and later.
   You need an administrator account.

2. Find the feature
   Search the list for EnableDateTimeCalendarListPickerView (the Code column). The grid is long, so use the browser's find or the page filter.

3. Switch it on
   Two scopes are available:

   1. State for current user — toggles the feature only for the account you're logged in with. Useful for testing. This rule takes higher priority than the rule applied to the user's group.

   2. Is enabled — the status for all users.
   3. Turn on the relevant switch and save. Front-end status changes require a browser page refresh to take effect; back-end changes do not.
4.  If the feature isn't in the list
   A feature that hasn't been added to Creatio is treated as disabled. You can add it manually from the same page: create a new record, set Code to EnableDateTimeCalendarListPickerView, add a description, and save. Creatio will populate the Source property with "DbFeatureProvider" automatically. 

Hello!

The no-code designer cannot do this. The "Apply static filter" dialog only accepts constants or current-user macros, and a business process can populate data but cannot filter a list on a page. To filter a list by a Text field of the current record, you need a few lines of code in the page schema. This is the documented Creatio approach for dynamic list filters.

Every list on a Freedom UI page has a data source attribute in viewModelConfig.attributes with a filterAttributes array. You add your own filter attribute there, then set that attribute to a sdk.FilterGroup in a handler. Whenever the attribute changes, the list reloads with the new filter.

Step 1. Add the SDK dependency

At the top of the page schema (UsrPreScreening_FormPage or whatever your form page is named):

define("UsrPreScreening_FormPage", /**SCHEMA_DEPS*/["@creatio-devkit/common"]/**SCHEMA_DEPS*/, function/**SCHEMA_ARGS*/(sdk)/**SCHEMA_ARGS*/ {

Step 2. Register a filter attribute on the list's data source

Find the data source for your Application list in viewModelConfig.attributes. It will look something like GridDetail_xxxx_DS or DataGrid_xxxx_DS. Add a new entry to its filterAttributes:

"GridDetail_Application_DS": {

    "isCollection": true,

    "modelConfig": {

        "path": "GridDetail_Application_DS",

        "filterAttributes": [

            { "name": "GridDetail_Application_PredefinedFilter", "loadOnChange": false },

            { "name": "GridDetail_Application_ActiveFilter", "loadOnChange": true },

            { "name": "UsrCustomerNameFilter", "loadOnChange": true }

        ]

    }

}

Keep the existing entries; only the last line is new. Also declare the attribute itself next to the others:

"UsrCustomerNameFilter": {}

Step 3. Build the filter in handlers

Add two handlers to the handlers array. The first sets the filter when the page opens. The second rebuilds it when the user edits Customer Name. Replace the attribute names with the real ones from your page (PDS_UsrCustomerName_xxxx and PDS_UsrApplicationNumber_xxxx), and the column names with the real Application object column codes.

handlers: /**SCHEMA_HANDLERS*/[
    {
        request: "crt.HandleViewModelInitRequest",
        handler: async (request, next) => {
            await next?.handle(request);
            await applyCustomerNameFilter(request.$context);
        }
    },
    {
        request: "crt.HandleViewModelAttributeChangeRequest",
        handler: async (request, next) => {
            if (request.attributeName === "PDS_UsrCustomerName_xxxx" && !request.silent) {
                await applyCustomerNameFilter(request.$context);
            }
            return next?.handle(request);
        }
    }
]/**SCHEMA_HANDLERS*/,

Then define the helper above the return { ... } of the schema module:

async function applyCustomerNameFilter(context) {
    const customerName = context.PDS_UsrCustomerName_xxxx;
    const appNumber = context.PDS_UsrApplicationNumber_xxxx;
    const filter = new sdk.FilterGroup();
    filter.logicalOperation = sdk.LogicalOperation.And;
    if (customerName) {
        await filter.addSchemaColumnFilterWithParameter(
            sdk.ComparisonType.Equal, "UsrCustomerName", customerName);
    } else {
        // no name yet: show nothing instead of everything
        await filter.addSchemaColumnFilterWithParameter(
            sdk.ComparisonType.Equal, "Id", "00000000-0000-0000-0000-000000000000");
    }
    if (appNumber) {
        await filter.addSchemaColumnFilterWithParameter(
            sdk.ComparisonType.NotEqual, "UsrApplicationNumber", appNumber);
    }
    // required workaround: the filter must be a plain object to trigger reload
    const plainFilter = Object.assign({}, filter);
    plainFilter.items = filter.items;
    context.UsrCustomerNameFilter = plainFilter;
}

The last three lines are not optional. The list only reloads when the attribute receives a new plain object, so copying the FilterGroup this way is the standard trick.

Notes

• Use sdk.ComparisonType.Contain instead of Equal if you want partial matches on the name.
• Column codes in addSchemaColumnFilterWithParameter are Application object column codes, not page attribute names.
• If you also want Date of Birth or ID Card matching, add more conditions the same way.
• The static filter you configured in the designer can stay or be removed. Your code filter combines with it through the PredefinedFilter attribute.

Alternative without code

If you can change the data model, make Customer a lookup object instead of a Text field and reference it from both the pre-screening record and the Application object. Then the standard list-to-page binding by lookup column filters automatically. That is the only no-code option, but it only works if a shared lookup makes sense for your data.

Hello,

First of all you read only 1 record in the "Read Insurance" read data element (it can be seen from the "First item of resulting collection" macro value). The sum of this will always be the value you read. I think something else was intended here.

Next, you can use Enumerable.Sum method, but you need to get an enumerable. Or introduce a method that can be called inside a script task like (and add Terrasoft.Core.DB to the process usings):

protected decimal GetInsurancePremiTotal(Guid insuranceTypeId) { //or any other argument suitable
    var query = (Select)new Select(UserConnection)
        .Column(Func.Sum("UsrPremi")).As("TotalPremi")
        .From("UsrInsurance").As("usrInsurance").WithHints(new NoLockHint())
        .Where("usrInsurance", "UsrTypeId").IsEqual(Column.Parameter(insuranceTypeId));
    decimal totalPremi = 0;
    using (DBExecutor executor = UserConnection.EnsureDBConnection()) {
        totalPremi = query.ExecuteScalar<decimal>(executor);
    }
    return totalPremi;
}

And set the result to process parameter and then use this parameter value to proceed in the business process.

Hello,

As far as I understood you need to filter options in the "Owner" filter dropdown list. There is only one option to do that - override the crt.LoadDataRequest as (and also include "@creatio-devkit/common" to the schema dependencies):

{
                request: "crt.LoadDataRequest",
                handler: async (request, next) => {
                    if (request.dataSourceName?.includes("ByOwnerQuickFilterInTimeline_ComboBox_List_DS")) {
                        const filterGroup = new sdk.FilterGroup();
                        await filterGroup.addSchemaColumnFilterWithParameter(
                            sdk.ComparisonType.Equal, "Name", "Supervisor"); //add other filters here
                            const filterParameter = {
                                type: "filter",
                                value: {
                                    filterType: 6,
                                    logicalOperation: 0,
                                    isEnabled: true,
                                    trimDateTimeParameterToDate: false,
                                    items: filterGroup.items
                                }
                            };
                            request.parameters = request.parameters
                                ? [...request.parameters, filterParameter]
                                : [filterParameter];
                    }
                    return await next?.handle(request);
                }
            }

You also need to confirm the data source name. The easiest way to do that is to add console.log("LoadDataRequest:", request.dataSourceName); to the crt.LoadDataRequest override and see which datasource is logged when you first click this "Owner" filter.

They don't as far as I've found with a few cases of wanting archiving unfortunately.

I've always had to do some workaround such as copying the data using automated SQL scripts into an exact copy of the object for archiving purposes (I have done this by creating a new Object and setting its parent to the Object that needs archiving). This has some downsides that any changes to the regular Object won't apply to the archive Object until you re-publish the archive Object, so something to look out for.

Another issue to watch out for is how the archived data references other data, e.g. if you have parent-child relationships and you are archiving by copying exactly using SQL, the archived record would still be pointing at a "live" record rather than an archived one. Again, custom solutions are required for this.

Overall it's quite a pain, and plenty of issues can arise. It would be great if there were a built in way of doing so.