CRM.win: Search Opens a Linked Child (C0xy) Record Without Switching the Active Company (FI) Context

Solution

Applies to

Aurea CRM (CRM.win Windows client)

Symptoms

You may observe the following behavior when working in a linked/custom dependent child info area (for example, a C0xy table under Company/FI):

• Running a search opens the matching child record.
• However, the UI does not switch the active Company (FI) context to the Company linked to that child record.
• The same type of search from a standard info area (for example Activities/MA) switches context as expected.

Information to collect before changing anything (for deeper analysis)

• The exact CRM.win version/build where the issue occurs, and the exact ACRM 8.3 build where it works (if applicable).
• SU_base.log (or equivalent CRM.win log output covering the search attempt).
• Screenshots showing:
  • the search being executed in the C0xy info area
  • the opened child record
  • the Company context not updating

If your uploaded files do not appear after submission, resend the logs/screenshots as email attachments (for example, by replying to the email thread you received so the attachments are included).

Workarounds / supported workflows

Option 1: Keep results tied to the currently opened Company (best for “search within this Company”)

Use this when you want results only for the Company currently open in the UI.

1. Open the target Company (FI).
2. Navigate to the linked/custom C0xy info area under that Company.
3. Open the Search dialog from that C0xy area.
4. Set Range = Current context.
5. Run the search.

Expected result: Search results remain scoped to the active parent context (the currently opened Company), avoiding the need for CRM.win to switch the Company based on the child record.

Option 2: If searching across Companies, open the child record and then navigate to its parent using hyperlinks

Use this when you intentionally search across multiple Companies.

1. Run the search that returns results across Companies.
2. Open the desired child record from the results.
3. Use CRM.win hyperlink navigation (for example, from the Summary Index Card and/or available hyperlinks in masks/lists) to jump to the related parent Company (FI).

Expected result: You can reach the correct Company via supported navigation even if opening the child record does not automatically change the active Company context.

Option 3: Go to the Company first, then work in the linked child area (often the cleanest workflow)

Use this when your end goal is to operate within a specific Company’s dependent child records.

1. Use Data > Company Search to locate and open the Company first.
2. Open the linked/custom C0xy info area under that Company.
3. Search again within that area (commonly with Range = Current context).

Expected result: Your work stays aligned with the correct Company context throughout the workflow.

How to validate the workaround

• Option 1 validation: While a specific Company (FI) is open, run a C0xy search with Range = Current context. Confirm the results belong to that Company and the displayed Company context stays consistent.
• Option 2 validation: Run a cross-company search, open a result, then use hyperlinks to navigate to the parent Company. Confirm the Company you land on matches the child record’s linked Company.
• Option 3 validation: Use Company Search to open a specific Company, then confirm all subsequent C0xy search and navigation occurs under that Company.

If the issue persists or the workaround doesn’t fit

If these workflows do not meet the business requirement (for example, you require an automatic parent context switch when opening child records from search results), gather the logs/screenshots listed above and provide:

• your exact CRM.win version/build
• the ACRM 8.3 build (if you are comparing behavior)
• customization details for the C0xy info area (link definition and where it appears under FI)
• steps to reproduce in a minimal scenario

This helps determine whether the behavior is a workflow/UX limitation in the relevant build or whether an additional configuration-specific problem exists.