Время создания
Filters
Service_Creatio_customer_center_edition
8.0

Hi!

I’m working on a Freedom UI Activities page where I display a registry of certificates as an editable list. One of the columns in this list is an Activity lookup, and I need to restrict that lookup to show only the current Activity (i.e. the one tied to the page).

So far, I’ve tried:

Implementing handlers for crt.OpenSelectionWindowRequest and crt.LoadDataRequest to log requests, but these only fire for fields outside the editable list.

Inspecting the Network tab: when I open the lookup dropdown, I see a SelectQuery against rootSchemaName":"Activity" with a filter, but I can’t find where to inject my custom filter for the editable list.

Question:
Does anyone have an example or best practice for applying a filter to a lookup column inside an editable list on a Freedom UI page? Specifically, I need the Activity lookup to return only the activity record corresponding to the parent page when the user clicks the field.

Thank you in advance for your help!

Like 0

Like

2 comments

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.

Show all comments

Hi Team,

I'm calling the custom web-service on the Customer Portal to fetch the role of the currently logged-in user: <strong>UsrUserInfoService/GetCurrentUserInfo</strong>. But the request is responding with 404 - Page Not Found error.

However, this service works as expected on the Employee Portal with the following endpoint: https://my.creatio.com/0/rest/UsrUserInfoService/GetCurrentUserInfo

I observed that the Requested URL differs slightly due to the presence of an additional path segment <strong>ssp</strong>, as shown below: `https://my.creatio.com/0/ssp/rest/UsrUserInfoService/GetCurrentUserInfo`

 

Thank you in advance

 

Like 0

Like

3 comments
Best reply

Add these attributes to your service class: 

[DefaultServiceRoute]
[SspServiceRoute]

Ryan

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

Show all comments
Freedom_UI
Classic_UI
Custom_Tab
Contact_Section
Customer_360
UI_Migration
page designer
App_Packaging

Hi Team,

I’ve been working on customizing the Contact entity in Creatio. Specifically, I added a custom tab with several fields and some logic to display data dynamically—this was all done within the Classic UI.

Later, I realized I need this customization in the Freedom UI, and I found out that installing the Customer 360 app is required to get the Contact section in Freedom UI. After installing it, I now see two versions of the Contact section in my app list:

  • One using the Classic UI (where my custom tab appears),
  • One under Customer 360, which uses the Freedom UI (where my custom tab is missing).

Here are the questions I need help with:

  1. Why is my custom tab visible only in the Classic UI version of the Contact section, and not in the Freedom UI one?
  2. Do I need to manually recreate the custom tab in the Freedom UI using the Page Designer, or is there a way to migrate it automatically?
  3. If I rebuild the custom tab in the Freedom UI, how do I package and export this customization (including layout and logic) to another Creatio instance?
  • I understand how to export an app and its code, but I’m unclear how UI changes in Freedom UI (like tab layout and fields) are handled in deployment/export scenarios.

I’d appreciate any guidance or best practices on migrating Classic UI customizations to Freedom UI, and how to maintain portability across environments.

Like 0

Like

1 comments

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

Show all comments

Greetings,

 

I would like to transfer the Attachments and Notes field when converting Leads to Opportunities.

However, upon looking at the Section Wizard, these are what the fields look like. The Notes field is not an ordinary text field.

Section Wizard page for Leads

Here is the process triggered when converting Leads to Opportunities.

Can someone please help me out with this? Thanks in advance.

Like 1

Like

2 comments

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?

Show all comments
Signals
Studio_Creatio_enterprise_edition
8.0

I am asking this because, I have an use case where a single data model requires to have triggers setup for multiple business processes. Is there any best practice regarding this like making a main process that will have all the triggers and run sub processes (multiple) based on what field is changed/added?
My current solution will be having all the process as having there own signals but I am afraid if this will slow down my creatio instance.

Thanks. 

Like 0

Like

2 comments
Best reply

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.

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) 

Show all comments