#Trailhead476 discutindo

Hi Ebony, 

Good news: these are pre-built actions that should already exist in the special superbadge org — you're not meant to build them in Challenge 1 (that's Exercise 2, where you create an Invocable Apex class). If they're not showing up, this points to one specific likely cause: you may not be using the special Developer Edition org that comes with this superbadge's pre-loaded Coral Cloud Resorts configuration and sample data. 

To check/fix: 

1. Confirm you signed up for the org through the "Sign up for a free Developer Edition org with special configuration" link on the superbadge unit page itself (Step I), not a generic playground or an existing DE org. This superbadge requires that specific special-config org — a regular org won't have these actions or the underlying Booking/Experience data at all. 

2. If you already have a different org connected, disconnect it and sign up fresh via that link, then reconnect. 

Once you're in the correct org, here's where to find them (per the official exercise walkthrough): in Agent Builder, when adding an action to your topic, use the Add Action search box: 

- Search "Recent" → select Get Most Recent Bookings by Contact 

- Search "Lookup" → select Lookup Experience 

- (Lookup Contact by Email should appear the same way — search "Lookup" or "Contact") 

These are found via search in that dialog, not browsed from a list — if you're clicking through a list instead of typing into the search field, that's worth double-checking too. 

If you've confirmed you're in the correct special-config org and searching properly and they still don't appear, that would point to an org provisioning issue worth reporting via Trailhead Help with your org details. 

Reference:

Hi Lena, 

Yes, removing API Enabled would impact the Salesforce Mobile App, since the mobile app requires API access. So I wouldn’t use that permission alone as the control for this requirement.  

A better approach is to keep API access for the users who need Salesforce Mobile and use API Access Control to restrict API access to only approved/allowlisted connected apps. Salesforce supports this model specifically for limiting API access while allowing approved apps.  

For report extraction, also control the Export Reports permission separately. Removing that permission prevents users from exporting report data, while folder sharing and report/dashboard permissions can be used to restrict access to sensitive content. 

I’d therefore treat this as multiple layers: API Access Control + Report/Folder permissions + Export Reports + subscription/access controls, rather than disabling API access entirely. 

You’re correct that there isn’t a direct trigger point here. ProcessInstanceWorkitem doesn’t support Apex triggers or record-triggered flows, and reassigning the approval doesn’t update the Case itself. 

If you need to keep the standard Reassign action, I’d handle it with scheduled Apex:

1.  Run a scheduled job every few minutes. 
2.  Query new ProcessInstanceStep records where StepStatus = 'Reassigned'. 
3.  Use ProcessInstance.TargetObjectId to identify the related Case. 
4.  Query the pending ProcessInstanceWorkitem for that process instance to get the newly assigned ActorId. 
5.  Insert a FeedItem with the Case ID as ParentId. 
6.  Store the processed ProcessInstanceStep.Id in a small custom log object with a unique/external-ID field. 
7.  Skip any step already in that log so rerunning the job can’t create duplicate Chatter posts. 

I’d also test it by reassigning the same approval twice and then running the job twice. The expected result should be two Chatter posts total, with no additional posts from the second job run. 

If real-time posting is absolutely required, the other option is to replace the standard Reassign experience with a custom Flow/LWC backed by Apex. That custom action would update ProcessInstanceWorkitem.ActorId and create the Case FeedItem in the same transaction. But the existing standard Reassign action can’t be intercepted directly.

Hi Cloud Crafter, 

Short answer: don't clone the app — generalize it. Build the integration logic once as a reusable, config-driven layer, then add the second API as a new configuration, not a new copy of the app. 

Why cloning is the wrong move: 

- Two copies of the same objects/flows/Apex means every future bug fix, security patch, or workflow change has to be done twice, and they will drift out of sync within months. 

- It roughly doubles your metadata footprint in the same org for no real functional benefit, since both integrations share the same overall structure anyway. 

- It makes testing, permissions, and reporting messier — you'll end up needing to explain to users/admins why there are two near-identical apps doing conceptually the same thing. 

Recommended approach: 

1. Extract what's actually integration-specific into configuration, not code/metadata. Things like endpoint URLs, auth credentials, field mappings, and payload structure should live in Custom Metadata Types or Named Credentials/External Credentials — not hardcoded per-integration Apex classes or per-integration Flows. 

2. Keep one set of core objects, screens, and automations, parameterized by an "Integration Type" or "Source System" field/record, so the same Flow/Apex logic branches or reads config rather than being duplicated. 

3. Use Named Credentials (or External Credentials with Named Principals) per third-party API. This is the standard Salesforce pattern for "same integration pattern, multiple external systems" — one generic Apex HTTP callout class, driven by whichever Named Credential/config record applies. 

4. If the two integrations genuinely have very different data models or business logic (not just a different endpoint), that's the signal to build a second app rather than force everything into one config-driven framework — don't over-engineer for reuse that doesn't fit. 

On sandbox vs. new org: stay in the same org/sandbox unless there's a hard business reason to separate (e.g., different client legal entities, data residency requirements, or genuinely unrelated user bases). A second full org means duplicating users, licenses, security model, and ongoing maintenance — that's a much bigger cost than it sounds, and it's rarely justified just because it's "a new integration." 

Common pitfalls to watch for: 

- Hardcoded field mappings buried in Apex instead of Custom Metadata — this is the #1 thing that makes the "just clone it" temptation so strong, and the #1 thing that makes maintenance painful later 

- Bulkification/governor limits — if the second integration runs concurrently with the first, make sure shared triggers/flows are bulk-safe, since now two integrations' worth of volume can hit the same automation 

- Error handling and retry logic tied to one specific API's response format — generalize this early, or you'll end up with API-specific error handling scattered everywhere

Hi @Rahul Khedkar

Yes, this can be handled using omniNavigateTo() from the Custom LWC that extends OmniscriptBaseMixin.  

this.omniNavigateTo('Step7'); 

Use the

of Step 7. This allows you to navigate directly from Step 2 → Step 7 without going through Steps 3–6. omniNavigateTo() is the supported approach for navigating to a specific step within the same OmniScript.  

Hope This Helps!!

Short answer: you generally cannot (and do not need to) write QuoteAccountId into the standard Quote.AccountId field. On the Quote object, AccountId is a system-derived, read-only reference that Salesforce fills from the related Opportunity's Account. It is not createable/updateable through the UI, Flow, Apex or the API, so an update like AccountId = QuoteAccountId will be rejected or ignored. For quotes created without an Opportunity, QuoteAccountId (label "Account for Quote") is the field Salesforce intends you to use as the account relationship. 

For your future Order process this is already covered: Salesforce's documentation for quotes without opportunities says associating the quote to an account is optional but recommended, because an account is required to convert the quote to an order. When you create an Order from such a quote, the account comes from the quote's account (QuoteAccountId), so you don't need Quote.AccountId populated. 

Practical recommendations: 

1. Make QuoteAccountId required (validation rule, e.g. ISBLANK(OpportunityId) && ISBLANK(QuoteAccountId)) so every quote can be turned into an Order. 

2. After enabling the feature, open Object Manager > Quote > Fields > Account for Quote and grant field-level security to your profiles/permission sets. It is hidden by default, which is why it often looks unavailable in Flow, reports and Apex. 

3. In reports, flows, sharing logic and Apex, use one source of truth, for example a formula field BLANKVALUE(QuoteAccountId, Opportunity.AccountId), so logic works for quotes with and without an Opportunity. 

4. If you create Orders yourself via Flow/Apex (rather than the standard Create Order action), set Order.AccountId = Quote.QuoteAccountId and Order.QuoteId = Quote.Id. 

References: 

Enable Quote Creation Without a Related Opportunity:

Release note, Create Quotes Without a Related Opportunity:

Quote object reference:

Assumption: the statement that Quote.AccountId is read-only is based on the Quote object reference field properties and commonly reported org behaviour; please confirm in a sandbox (e.g. attempt the update in a Flow or Developer Console) before designing around it.