#Solution Architects11 discussing

Hello @Abhishek Sinha

Package conversion and migration to 2GP only work for managed 1GP packages. Unmanaged packages can't be converted. For those, you rebuild the package from its source. 

If it's an unmanaged package:

1. Retrieve the package's metadata into a Salesforce DX project:

  sf project retrieve start --package-name "<Package Name>" --target-org <org>

  Then convert it to source format if needed: sf project convert mdapi.

2. Create a new package from that source. Use an unlocked package for internal/org use, or a managed 2GP package if you're an ISV distributing on AppExchange:

  sf package create --name "<Name>" --package-type Unlocked --path force-app

  sf package version create --package "<Name>" --installation-key-bypass --wait 20

3. In existing orgs, the unmanaged components aren't linked to any package. Install the new package and test it in a sandbox first. Unlocked packages can take ownership of existing unpackaged metadata (see "Migrate Existing Metadata to Unlocked Packages" in the docs).

If it's a managed 1GP package, Salesforce supports conversion and migration in three phases:

1. Plan and test: keep releasing with 1GP. Convert and migrate only in scratch orgs or sandboxes. Get all subscribers onto the same 1GP version.

2. Transition: convert your latest major.minor released version, promote it to released, then migrate subscribers with push upgrades (one time per subscriber). New features are still built in 1GP, then converted and push-upgraded.

3. Fully on 2GP: confirm the move in your packaging org's Setup. After that, you can no longer create new major/minor 1GP versions (only patches for earlier versions).

The subscriber's installed 1GP version must match the major.minor.patch version of the converted 2GP version you migrate them to. Migration doesn't change your metadata or subscriber data. 

• Plan your migration: https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migration_planning.htm
• Before you begin: https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migration_prerequistes.htm
• Considerations: https://developer.salesforce.com/docs/atlas.en-us.pkg1_dev.meta/pkg1_dev/migrations_known_limitations.htm
• Trailhead, 2GP managed packages: https://trailhead.salesforce.com/content/learn/modules/second-generation-managed-packages

@Lena Wong

You're right the business rule doesn't care who owns the Quote. The risk comes from how the platform stores the share, not from the rule. 

Where the Quote owner matters (platform mechanics, not business logic) 

A Flow created QuoteShare is a manual share (row cause "Manual"). Salesforce deletes manual shares on a record when that record's OwnerId changes. Your Flow most likely triggers on events like Quote created or Account owner changed. A Quote owner change isn't one of those events, so: 

1. The ERP (or a user or mass transfer) changes the Quote's owner.
2. The platform silently deletes the share the Flow created.
3. Nothing re-runs the Flow, so the Account Owner loses access even though the business rule says they should have it.

Fixes, in order of preference: 

• Add a trigger path on Quote update when OwnerId changes, so the Flow recreates the share.
• Add a scheduled reconciliation that compares expected and actual shares. This also catches other drift.

A related edge case:

if the Account Owner is also the Quote owner, they already have access. The Flow should skip creating the share in that case, because inserting a share for the owner is rejected or ignored. 

(it creates Quotes under a fixed integration user and never updates them), this risk mostly goes away, and the Account owner, region, and bulk-load gotchas are what remain. I can't confirm that from here, so it's worth asking the ERP team. 

If every sales user is in the same Permission Set Group, that group can't tell Field Sales from back-office, so it doesn't help as the identifier. Option 2 only works with a separate, standalone permission set (for example

Hey Jiyaulla,

Here’s how I would approach the solution design:

1. Agent Boundaries & Routing

• Split by persona: Don't build one monster agent. Keep Employee Desk (IT/HR Q&A via Knowledge), Coworker (sales/service reps on record pages), and OOTB Service Agent in clean, separate buckets.

• Topics & Hand-offs: Limit each agent to 4–6 tightly scoped Topics. Write explicit "When to use" instructions so the reasoning engine doesn’t cross wires. Always map human escalation via Omni-Channel, carrying the chat summary over.

2. Actions & Grounding (The Engine)

• Actions: Use Autolaunched Flows for standard CRM updates and Invocable Apex for external API lookups. Keep JSON outputs short; feeding raw multi-page payloads burns tokens and slows reasoning down.

• Flex Prompt Templates: Stick to a 4-part prompt: Role, Grounded Context, Guardrails (what NOT to do), and exact Output Format.

• Knowledge & Data Cloud: If grounding with PDFs or policies, ensure your Data Cloud search indexes chunk properly. Watch Field-Level Security—if the running agent user can’t see the field, the LLM hallucinates.

3. Trust, Guardrails & Security

• Einstein Trust Layer: Decide upfront if PII needs data masking and where audit logs get retained.

• Hard Refusals: Put explicit negative prompts inside each topic (e.g., "Never disclose salary bands; route user to Workday").

4. Licenses & Consumption Reality Check

• Cost control: Agentforce bills per conversation, and custom prompt calls burn credits. Don't use the LLM for things a simple Flow lookup or formula can solve deterministically.

• Token limits: Heavy record grounding causes latency spikes. Keep grounding payloads minimal.

5. ALM & Deployments (Where Projects Trip Up)

• Metadata API: Topics, Actions, and GenAiPromptTemplate deploy through standard DevOps pipelines (Copado, Flosum, SFDX).

• Manual Post-Deploy: Playbooks always break here. You must manually:
  1. Assign permissions and FLS to the Agent Execution User.
  2. Activate the Agent version in Target Org.
  3. Validate Data Cloud search index syncs.

Hi Piyush, 

1. You're right, mTLS is the wrong tool here. mTLS operates at the application/TLS layer after a TCP connection is already established — it proves identity to something that's already listening and accepting connections. If the vendor's firewall is dropping packets before that handshake even starts, no client cert changes that. mTLS solves "who is this," not "can this even reach me." 

2. Private Connect is AWS PrivateLink-based only, so it's natively usable when the target sits in an AWS VPC. Azure targets aren't natively supported — you'd need inter-cloud private peering (AWS↔Azure via ExpressRoute/Direct Connect + a transit arrangement) which Salesforce doesn't self-serve; that requires your account team and is a heavier lift. No public roadmap confirmation of native Azure PrivateLink support as of now. 

3. No native mechanism gives an Apex callout a narrower/tenant-specific egress identity beyond the published IP ranges — that's the actual gap you've identified. The published Hyperforce ranges are deliberately shared infrastructure-wide, not per-org, so it's a network-layer allowlist, not an identity boundary. There's no equivalent of "static NAT per org" for outbound Apex callouts today. 

4. Yes — a relay/gateway in front of the private service is the standard, recommended pattern here, and I'd recommend it. Put a lightweight reverse proxy (or MuleSoft Anypoint, or even a small managed API gateway) in a publicly reachable spot the vendor controls, with the vendor's actual private-network service sitting behind it. Salesforce calls the gateway over the public internet (allowlist-friendly, small surface), and the gateway — sitting inside the vendor's trusted network — forwards to the private endpoint. This gets you real identity-based control (API key, mTLS, OAuth — now actually meaningful since the gateway is an app-layer listener) instead of a shared-IP-range network allowlist, and it decouples you from Salesforce's outbound range changes entirely, since your callout target becomes a stable endpoint the vendor owns. This is what most orgs land on for exactly this scenario — it's a small piece of infra to own, but it's the durable fix. 

Reference: