@jlinster the idea is to be on full-site SSL prior to Chrome release 68 dropping in July. This can be done at any point, but will require some work to be done on both sides.
In addition to enabling SSL or switching from partial to full-site SSL, we'll need to review your studio content and change any hard-coded HTTP links to HTTPS. Additionally, if you have any hard-coded links in the admin panel (custom content modules, announcements, etc.), you'll need to change those to use HTTPS or a relative path.
... View more
Some tips before escalating
In the case portal, you have the ability to set/change the "Customer Priority" field between low, normal and high. When issues are urgent but not necessarily world ending, changing the priority to "high" will push it up the list of issues based on your support level, which is a good way to get support's attention to an issue.
One thing to avoid if possible is creating a case and escalating it that same day without a strong reason. Same day escalations are generally pushed back on to allow them to go through the standard support triage process and gather all necessary information before bringing in other experts or teams, but short-cutting tends to be disruptive to that process and introduces further delays.
While it is important to stay in close contact with your CSM or account rep, we strongly recommend bypassing them for escalations and instead escalating directly via the case portal. Ad-hoc escalations create back channels and can duplicate efforts, which has resulted in delays or confusion around escalations. CSM's are also informed around escalations automatically, so they will be aware.
When should I escalate?
You should escalate when there is urgency involved in a support ticket. This would include issues such as, but not limited to:
Time constraints (SSL cert expiring, deadlines, events, etc.)
A major impaired function that does not qualify as an severity 1 issue
SLA missed for first response
Unresponsive or lack of updates in a case
While we'll do our best to keep it to a minimum, there will be times when escalated issues will not be accepted as an escalation. If/when that happens, an automated reply will be sent to inform the user who originally escalated the case. Decisions around escalations are entirely at the discretion of the team responsible for escalations.
Additionally, the escalation feature is not designed to replace the outage alias. Any issue which qualifies as being of outage severity should continue to go through the standard outage process of emailing email@example.com or setting the case severity to "1".
How do I escalate a support case?
After a case has been created, the option to escalate it will be available. Simply open the desired support ticket within the Case Portal and click Escalate Case located under the case details near the bottom left-hand corner.
A new form displays along with some details and instructions. On that form, provide a summary of why the case needs to be escalated to an Escalation Manager for review within 4 business hours.
After you've filled out the escalation summary and submitted the request, an alert is sent to an Escalation Manager for review. An Escalation Manager will review the request and reply directly in the case you escalated with a decision or plan of action.
What if I'm not satisfied with the current escalation decision or progress?
Should you be unsatisfied with the results of your case escalation, you have the option to go up a higher level by clicking the "Escalate Case" button again. When the "Escalate Case" button is used again, you'll be presented with a different form acknowledging the next-level escalation and again requesting you provide an explanation around the reason for escalating again / higher. Once submitted, an Escalation Manager will review the request and respond directly within the escalated case.
You can perform this process multiple times. The higher the escalation, the more members of Leadership or Management will be involved. Here's a breakdown of the various levels and what occurs:
Level 1: The case is escalated to a team of Escalation Managers, who will review and reply in the case.
Level 2: The case is escalated to the Escalation Managers, Support Management and your account's Customer Success Manager (CSM), but the Escalation Managers will review and respond.
Level 3: All of the previous manager groups from Level 2 are alerted, but in addition the Regional Senior Management is also included and will personally review and reply to your case.
Level 4: All of the managers from Level 3 are alerted, but VP of Support is also alerted. The VP will review and reply directly to the case. A full root cause analysis will be completed to understand why this case needed an escalation to this level.
... View more
It appears the (now) old thread fell through the cracks, so I do apologize for that going unanswered and will work with our community team to ensure we do better at capturing and responding to all topics that go unanswered. While I could certainly see this being a "strategy" discussion, it's also a Support item, for sure. We utilize the escalation feature on the support section of the community so if a thread goes unanswered for 4 hours, the feature emails support and creates a case on your behalf. All of that said, I'll see how the strategy section is configured so content posted there gets similar treatment or at least emails a designated contact to follow up and take action.
Back on topic - I see case 00143330 was marked as resolved back on 6/19 and would love to know if the information provided there resolved your issue or not. For the sake of the community and spreading information in the event this topic pops up in someones search results, I can drop some information here as well.
This is actually a little different in that most customers go from non-SSO -> SSO rather than the other way around. When moving from an SSO system to the basic Lithium authentication system (non-SSO), the following would occur:
SSO users would not be able to login to the community
Any account created while SSO was disabled would be a non-SSO account and unable to login once SSO was turned back on
Non-SSO accounts can be reconciled / converted into SSO accounts, but not the opposite way around
Curious, are you looking to do this for a short period or time or indefinitely?
P.S. Thanks @JulieHamel for the assist!
... View more
Node ID's can't be changed so it sounds like these are two different knowledge bases, in which case both would be accessible. We can add a redirect from the old one so it forces users to the new one, if that would help.
... View more