Hello,
You can find the examples and additional information in the following posts:
https://community.creatio.com/questions/applying-filter-lookup-field-inline-editing-details-record-freedom-ui-detail-object
https://community.creatio.com/questions/freedom-ui-filtration
https://community.creatio.com/questions/freedom-ui-lookup-filter
https://community.creatio.com/questions/filtering-lookup-values-editable-list-grid-detail#comment-87531

The example provided in the article might be useful as well
https://academy.creatio.com/docs/8.x/dev/development-on-creatio-platfor…
 

Iryna Oriyenko,

Hi Iryna,

Thank you for gathering these links for me. I reviewed each of them and successfully implemented the lookup filter on a Freedom UI Form Page. My challenge now is applying the same filter to a Freedom UI List Page (the editable grid inside a section).

I’ve seen mixed information in the community: some comments say inline filtering in the List Page grid isn’t supported yet, while others suggest it might be possible - but I haven’t come across a working example.

Could you confirm whether dynamic lookup filtering in a edit List Page grid is currently supported? If it is, a short code snippet or reference would be greatly appreciated.

Thanks again for your assistance.

Add these attributes to your service class: 

[DefaultServiceRoute]
[SspServiceRoute]

Ryan

Hi Ryan,

After adding attributes, still getting compilation error below:


I am providing you with source code of service:

using Terrasoft.Web.Common;

using System.Web;

using Terrasoft.Core.Factories;

using System;

using System.Data;

using System.Data.SqlClient;

using System.Collections.Generic;

using System.ServiceModel;

using System.ServiceModel.Web;

using System.ServiceModel.Activation;

using Newtonsoft.Json;

using Terrasoft.Core;

using Terrasoft.Core.DB;

using Terrasoft.Common;

using Terrasoft.Core.Entities;

namespace Terrasoft.Configuration.UsrUserInfoService

{

    [ServiceContract]

    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]

    [DefaultServiceRoute]

    [SspServiceRoute] 

    public class UsrUserInfoService : BaseService

    {

       [OperationContract]

        [WebInvoke(Method = "GET", UriTemplate = "GetCurrentUserInfo", ResponseFormat = WebMessageFormat.Json)]

        public string GetCurrentUserInfo()

        {

            // Fetching Current Logged-in User Role

        }

    }

}

souresh khandelwal,

Sorry, forgot to also mention to add these usings: 

using Terrasoft.Web.Common;
using Terrasoft.Web.Common.ServiceRouting;

Ryan

Freedom UI and Classic pages are completely separate. Anything previously added to a classic page would have to get recreated on a Freedom UI page. There is no automatic conversion or migration. You just have to create it again. 

Ryan

You can use the Process File element to do this. It can read all the attached files from the Lead and save them to the opportunity (all with one single element). 

You could either add it to the process you included a screenshot of, or a separate process that just listens for the Opportunity getting filled in on a Lead. 

Note, this will make it so the files exist in both records. If wanted, to avoid the duplicate files, you could follow it up with deleting them from the lead after copying with Process file. 

Ryan

Hi, Ryan,

Thanks for replying. I tried out the "Process File" element and inserted it after the "Edit Lead to Add Opp" modify data element. I do want the attachments and notes to be present in both the Lead and the Opportunity.
However, when I tried testing the process, the attachments and notes weren't transferred upon lead conversion. Am I missing something?

Hello,

In Creatio, signals are event-driven triggers used to start business processes when a particular event occurs on an object, typically the addition, update, or deletion of a record. When a process contains a signal element, it essentially subscribes to a specific system event. When that event is raised, Creatio evaluates all matching subscriptions and initiates the corresponding processes.

In the case where several processes need to respond to changes on the same object but based on different business tasks (such as changes to specific fields), there are generally two architectural approaches. One is to define separate business processes, each with its own signal element. These processes start independently whenever the triggering event occurs and include internal logic to determine if they should proceed based on the field changes. The other is to design a single process with a more general signal and then route the execution flow internally, either through conditional logic or by invoking subprocesses depending on which fields were modified.

Both methods are valid and widely used in different Creatio implementations. The choice between them often depends on the nature of the business logic, the level of process reuse, and how centralized you want the control and evaluation logic to be. Having separate processes allows for more modular and decoupled logic, which can be beneficial for maintainability. A unified dispatcher-style process offers better coordination and visibility but may introduce more complexity up front.

From a performance perspective, it’s important to note that the number of signal-based triggers alone is not typically the main factor that impacts system performance. Rather, it is the overall process design, how much logic is executed, whether service calls are involved, and how efficiently process elements are structured. In environments using RabbitMQ, Creatio is more likely to offload process execution to the background automatically.

If you encounter any issues with a specific process or signal behavior, we recommend creating a support ticket via the Success Portal. Our support team will assist in analyzing and resolving the issue.

Nick Ovchynnik,

Thank you for the reply. I will keep implantations simple for now, hopefully no performance impact (fingers crossed)