Agentforce Education (Education Cloud)

Hi Saqib - happy to give you a systematic way to run this down. The single most common cause of 'some users can't access Education Cloud features' is a missing Permission Set License, so I'd start there and then work through the access layers in order. 

1. Permission Set Licenses first. Education Cloud features are gated behind permission set licenses (PSLs) - the feature-specific permission set grants nothing until the matching PSL is assigned to the user. Check Setup > Users > [the user] > Permission Set License Assignments and confirm the Education Cloud PSL(s) are there. This is the step people miss most. 

2. Then the permission sets / permission set groups. Confirm the user has the standard Education Cloud permission sets assigned (the product ships persona-based sets), and that they grant object CRUD, field-level security on the fields in question, and any system/feature permissions the feature needs. 

3. Separate 'can't see the object/tab' from 'can't see the records'. If they can't open the object or tab at all, it's CRUD / tab visibility / PSL / app assignment. If they can open it but see no records, it's record access - org-wide defaults, sharing rules, role hierarchy, or sharing sets for Experience users. Treating those two symptoms differently saves a lot of time. 

4. App + Lightning page. Make sure the right app and tabs are visible to their profile, and that the Lightning record/home page showing the feature is actually assigned to their app/profile - a component can silently disappear if the page assignment doesn't cover them. 

5. Fastest diagnostic: Login As the affected user (if enabled) and reproduce - you'll see exactly what's missing far quicker than auditing config. 

If you can share the specific feature/object they can't reach and whether they get 'insufficient privileges', a blank tab, or empty records, I can point you straight at the layer. The Salesforce Help 'Education Cloud' setup docs also list the exact PSLs and permission sets per feature. 

Hope that helps you narrow it down!

@ANANTHARAMAIAH VENKATA POCHINCHARLA

The fact that Agent Preview works while Enhanced Web Chat fails is the single most useful clue here. It tells us the agent itself, its topics, and its actions are fine. Agent Preview bypasses the routing layer entirely and talks to the agent directly. Enhanced Web Chat goes through Messaging, Omni-Channel routing, and then to the agent. So the break is somewhere in that routing chain, not in the agent. 

That narrows it a lot, and it also points at your fourth question, which I think is closest to the real answer. 

On Developer Edition and backend provisioning, this is where I'd look first. Messaging for In-App and Web with Enhanced Messaging requires Digital Engagement provisioning, and Developer Edition orgs frequently do not have the full Enhanced Messaging backend provisioned even when every Setup screen lets you configure it successfully. That's the trap: Setup will happily let you build the channel, the deployment, and the routing, and everything will look correct, but the underlying messaging infrastructure that actually delivers the conversation to the agent was never turned on. "Agents are not available" is the generic front-end message when that chain can't complete on the backend. This matches your symptom precisely, including the fact that Salesforce's own Test Enhanced Web Chat fails identically, which rules out your snippet and your site.

On the EinsteinServiceAgent user, this is worth verifying carefully because it's the second most likely cause. The Agentforce Service Agent runs as its own dedicated user, and that user needs to be properly configured to receive work. Specifically, confirm the agent user has the Agentforce Service Agent permission set (or the relevant Agentforce permission set license) actually assigned, and confirm the agent user is enabled for Omni-Channel with a presence configuration that includes the Messaging service channel. A very common failure is that the human Omni-Channel user is set up perfectly (which you've done) while the agent user itself is missing the Omni presence configuration or the permission set license, so routing has nowhere valid to deliver the work. Your checklist covers your own user's availability, but the agent user is a separate identity with its own requirements.

On non-obvious prerequisites, a few to verify:

Confirm Omni-Channel itself is enabled and that a Service Channel record exists specifically for Messaging Session, not just Messaging. The routing has to resolve to a Service Channel tied to the MessagingSession object.

Check that your Messaging Channel is actually associated with the Embedded Service Deployment you're testing from, and that the deployment is using the Enhanced (v2) messaging type rather than a legacy configuration. Mixing a legacy channel with an Enhanced deployment produces exactly this kind of silent routing failure.

Verify the Omni-Flow is actually being invoked. Open your NovaMart Chat Routing flow and check whether it has any recent runs, or add a temporary debug element. If the flow never fires, the failure is upstream of routing entirely, which again points to provisioning. If it fires and then fails at Route Work, the problem is the agent user's ability to receive.

My honest read on your four questions: yes, this is common in Developer Edition specifically; the non-obvious prerequisite is Digital Engagement / Enhanced Messaging backend provisioning; the EinsteinServiceAgent user does need its own permission set license and Omni presence configuration beyond what you'd set for a human user; and yes, there is backend provisioning that Salesforce must complete, and in a Developer Edition org that provisioning often simply isn't there and cannot be self-enabled from Setup.

The fastest path to certainty: check whether your Omni-Flow is executing at all. If it never runs, you have your answer and it's provisioning. If it runs and fails at Route Work, focus on the agent user's permission set license and Omni presence configuration. Either way, if you can test the same configuration in a trial org or a sandbox of a fully provisioned org and it works there, that confirms Developer Edition provisioning as the culprit and saves you from chasing config that was never wrong.

Given the effort you've clearly put into the setup, I'd also just log a case with Salesforce Support and ask directly whether Enhanced Messaging and Digital Engagement are provisioned on your Dev org. That's a question only they can answer definitively, and it takes them minutes to check.