Skip to content

[ASIM] Create authentication parser for SalesforceServiceCloudV2_CL#14423

Closed
yummyblabla wants to merge 9 commits into
masterfrom
asim/authentication-salesforce-servicecloud
Closed

[ASIM] Create authentication parser for SalesforceServiceCloudV2_CL#14423
yummyblabla wants to merge 9 commits into
masterfrom
asim/authentication-salesforce-servicecloud

Conversation

@yummyblabla

Copy link
Copy Markdown
Collaborator

Create authentication parser for SalesforceServiceCloudV2_CL
See CHANGELOG for details

@yummyblabla yummyblabla requested review from a team as code owners June 5, 2026 22:48
@contentautomationbot

Copy link
Copy Markdown

ASIM parsers have been changed. ARM templates were regenerated from the updated KQL function YAML files.
To find the new ARM templates, pull your branch.

@SpeedyFireCyclone SpeedyFireCyclone left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the work @yummyblabla & @hunngu-ms, I've dropped my pull request in favor of this one. I do have some suggestions regarding supporting of the V2 table and not the V3.

The V2 table was introduced when the Data Connector moved to CCP. Some fields that were available in the legacy connector it replaces were not initially included, and were added to the V2 schema later: PR 13150, PR 14144. Because the table was updated and did not receive a new version number some fields may be missing from certain environments. (I checked and there is no use of those fields in this parser). A later PR (#14180) fixed this and bumped up the table name to V3, which should become the more commonly used table as the connector gets updated across Sentinel instances.

pack: bool = false
)
{
SalesforceServiceCloudV2_CL

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latest version of the Salesforce Service Cloud connector refers to the SalesforceServiceCloudV3_CL table, after several fields that were available in the original connector were not ported over to the CCP-based one.

Suggested change
SalesforceServiceCloudV2_CL
union isfuzzy=true
SalesforceServiceCloudV2_CL,
SalesforceServiceCloudV3_CL

// -- Build ASIM fields
| extend
// -- Event fields (Mandatory)
Type = "SalesforceServiceCloudV2_CL",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This field is populated by default by the underlying table.

Suggested change
Type = "SalesforceServiceCloudV2_CL",

pack: bool = false
)
{
SalesforceServiceCloudV2_CL

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as noted the non-filtering parser;

The latest version of the Salesforce Service Cloud connector refers to the SalesforceServiceCloudV3_CL table, after several fields that were available in the original connector were not ported over to the CCP-based one.

Suggested change
SalesforceServiceCloudV2_CL
union isfuzzy=true
SalesforceServiceCloudV2_CL,
SalesforceServiceCloudV3_CL

// -- Build ASIM fields
| extend
// -- Event fields (Mandatory)
Type = "SalesforceServiceCloudV2_CL",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as noted the non-filtering parser;

This field is populated by default by the underlying table.

Suggested change
Type = "SalesforceServiceCloudV2_CL",

@yummyblabla

Copy link
Copy Markdown
Collaborator Author

Hi @SpeedyFireCyclone
Yes, there is the V3 of the Salesforce ServiceCloud connector. This is targeting the V2 connector.

I see your PR and its aim is to union the 3 tables, original, V2, and V3. I think I would prefer your solution better given the history of it. I wanted to separate V2 and V3 parsers because of the schema differences, but since V2 has different variations where some environments may not have certain columns, I don't think we can get away from using column_ifexists, which is what I wanted to stay away from originally by separating V2 and V3.

We can go ahead with your PR instead as I would agree with your solution.

@SpeedyFireCyclone

SpeedyFireCyclone commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

Hi @SpeedyFireCyclone Yes, there is the V3 of the Salesforce ServiceCloud connector. This is targeting the V2 connector.

I see your PR and its aim is to union the 3 tables, original, V2, and V3. I think I would prefer your solution better given the history of it. I wanted to separate V2 and V3 parsers because of the schema differences, but since V2 has different variations where some environments may not have certain columns, I don't think we can get away from using column_ifexists, which is what I wanted to stay away from originally by separating V2 and V3.

We can go ahead with your PR instead as I would agree with your solution.

@yummyblabla, Sorry I completely missed your comment, I've reopened my pull request: #14215

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants