ÃÛ¶¹ÊÓƵ

Transcript

All righty.

Is everyone able to hear and see me? Looks like we’re all coming back through a consent window. Oh there I am. Okay, good to see everyone. Thank you for joining today. I’m super excited to have us all here together to learn about the new ÃÛ¶¹ÊÓƵ Admin console migration that you may have heard about. We have some folks from our product team here to discuss this with you all in sort of a train the trainer style format that I know we’ve done in the past. So hopefully you can take this information, use it for your own purposes and your own sort of knowledge with this migration coming, but also help to educate our larger community by speaking with their user group chapters about this topic and helping them understand this coming migration.

But before we get into the content, I do want to introduce Daylinn Hereford. As you may have seen in Slack and on email, from now until the end of Thanksgiving, or sorry the end of November, Thanksgiving for us US-based folks, I’m going to be stepping into the role of advocacy team lead while Kelsey Biondick, our advocacy team leader, is out on maternity leave. So while I’m in that role with some additional responsibilities, Daylinn will be joining us to lead the MUGS program. So she’ll be your sort of day-to-day contact while I’m filling in for Kelsey until the end of November. So Daylinn, I’ll let you introduce yourself and then we can get started.

Great, great. Thanks Emma and hello everyone. And now I’m still making my rounds a little bit with some of the intros. So I see some of you on the call that I’ve connected with, but to those of you that I have not, I’m Daylinn Hereford. I’m currently based in Nashville, Tennessee. I’m originally from Huntsville, Alabama and I’m super, super excited to work with this amazing program and step into this role through November. So I’m coming to you guys from Salesforce where I supported our Slack customer marketing programs for CNT, retail, and Fins customer industries. And I also spent a couple years at Oracle supporting their go-to-market campaigns team. So I have a wide array of customer knowledge. I’m super excited again. I can’t reiterate enough how amazing this program is and super excited to meet everyone and continue making my intros along the way. But thanks for the warm welcomes and I will hand it back over to Yuri to kick us off.

Great, thank you. Hi everyone. My name is Yuri Hiyohashi. I’m a product manager for MarketoEngage and I work with Stephanie Simmons. Some of you may already know her and I focused on MarketoEngage migration, today’s topic.

So overarching objective for today is to enable you to, with the knowledge and resources to help your organization and your chapter members who are embarking on the migration journey to ÃÛ¶¹ÊÓƵ Identity. As you may know, for almost a year ÃÛ¶¹ÊÓƵ has been migrating Marketo customers to ÃÛ¶¹ÊÓƵ Identity and it’s been tied to sales events. But later this summer we are going to start migrating without these prerequisites. So this means we are picking up on our pace for migration and need to prepare a broader set of Marketo customers for the migration days to come. So we’re hoping that you can help us. To this end I’d like to start with a brief overview of what it means for MarketoEngage to be on ÃÛ¶¹ÊÓƵ Identity.

Going with a high level overview of a migration journey.

Then we’ll dive deeper into four key areas of user migration.

Then I’ll share links to some of the helpful resources you can use and before going over what the next steps are for your organization and your chapter.

Then we conclude the session with a Q&A. Okay there you go.

Okay so this section is mainly for Marketo only customers and who may not have had a prior exposure to ÃÛ¶¹ÊÓƵ Identity and Admin Console. So some of you may already know but just as a refresher. The notable difference between ÃÛ¶¹ÊÓƵ ID and Marketo ID is that ÃÛ¶¹ÊÓƵ ID is based on unique email address and email verification is mandatory for ÃÛ¶¹ÊÓƵ ID users and if multiple email addresses are associated to a single Marketo ID then ÃÛ¶¹ÊÓƵ will ask to resolve the conflict during the email verification process. Admin Console is an online tool provided by ÃÛ¶¹ÊÓƵ where you manage your ÃÛ¶¹ÊÓƵ product licenses and users including MarketoEngage after migration.

And there will be a set of administrators and we’ll cover them next. So user management on ÃÛ¶¹ÊÓƵ Console focuses on managing product access to MarketoEngage but the roles and permission will remain in the admin section of the product.

And finally ÃÛ¶¹ÊÓƵ Org is a conceptual holding place for a set of a product to own any of your users. ÃÛ¶¹ÊÓƵ ID and Admin Console will have a one-to-one relationship if you have only one product but there can be many other the Orgs if you have multiple products and wish to manage them separately. ÃÛ¶¹ÊÓƵ Org can be based on each cloud of products geographical location or subsidiary for example to meet whatever your business needs.

And just to note that these multiple Orgs can be linked and accessed from a single org or any other product. So if you have multiple products and wish to manage them separately you can use ÃÛ¶¹ÊÓƵ Org or Admin Console using what’s called an Org Selector on the home screen. And it appears here as you see it says Acme HQ and here’s a drop down it’s a little bit blurred but there are multiple Orgs listed here and which you can select from. And so as you can see you can toggle between multiple Orgs seamlessly if you have access to more than one Org.

As I mentioned there are several admin roles on Admin Console that are new to market only customers. Starting with ÃÛ¶¹ÊÓƵ System Admin who sits atop this admin hierarchy and this person determines the organization’s identity management strategy and then computes it on Admin Console. And at least one System Admin must be assigned when ÃÛ¶¹ÊÓƵ Org is initially set up. If you think you need more than one or change the System Admin from the existing person you can contact market or support.

ÃÛ¶¹ÊÓƵ Product Admin is primarily responsible for entitling users to the product and System Admin can grab this role to a user or user who is not in the system. This role to a user or users on Admin Console.

The next one the Product Profile Admin which is probably a new concept for market or customers. Product Profile at least for other ÃÛ¶¹ÊÓƵ products can be used when one group of users needs a different level of product entitlement for the same product from another group of users. And the Product Profile Admin can assign some users to one product profile and while others to another product profile to accomplish this. While marketer users too will need to be assigned to a product profile of a given subscription to gain product access but if even if multiple product profiles are set up for this subscription it doesn’t relate back to Marketer Engage. It doesn’t know which product profile it belongs to on Admin Console. Hence users need to be assigned to any product profile associated to a subscription that they won’t access on the Admin Console.

So by now you may have figured out that each subscription needs to be associated to at least one product profile on Admin Console and one will be automatically created for each and all migrated subscription. I just wanted to cover this in a little bit more detail because there are some confusion out there hopefully this clarifies that. Product Support Admin will have access to contacting Marketer Engage support when support portal transition is complete for his or her subscription.

The existing authorized support contacts who are migrated to ÃÛ¶¹ÊÓƵ Identity will be granted this role automatically and till the user migration starts the authorized support contacts will be creating and viewing the case in the existing support case portal on the marketing nation. And finally Marketer Engage Admin who is known as Marketer Product Admin that you’re familiar with and while all other admins are granted role on the Admin Console this one is granted in the product and have administrative privileges within the product like they have been without the user management capability after the migration.

Okay now we’re going to switch gears and go over the migration journey at a high level. Okay so this is the quick reference guide that you all want to have it handy during your journey and all the key info is on this one slide the changes actions you may need to take and the communications you will receive from the migration journey. This is a high level overview with lots of information and we’ll dive deeper into key areas in subsequent slides.

Okay so it all starts with subscription migration also known as product migration.

So let’s go back to the migration journey and see how it all works. So here we have the subscription migration also known as product migration.

ÃÛ¶¹ÊÓƵ provisions your marketer subscriptions on Admin Console and there you will see a marketer product card appears. At this time no changes to user management or how the user will log into the system. The system admin will receive an email indicating that product migration is complete and this email will have a link to provide a consent to add marketer users to existing admin console if other products are managed there. Also it informs to set up SSO if your subscription had it previously.

After SSO is configured and the consent is provided if they’re applicable ÃÛ¶¹ÊÓƵ will schedule a migration start date.

This is a default date that is set 30 days in the future and marketer admins can modify this default date in the pre-migration console which we’ll touch on it later in more detail. Admins are encouraged to communicate to users about the upcoming migration and prepare them.

Some users may still need to verify their emails.

System admin and the product admins will receive an email from ÃÛ¶¹ÊÓƵ that the user migration date is scheduled. And next one week before the scheduled migration start date, admins will no longer be able to modify the start date on the migration console.

It locks because of the complexity of user migration. If you must change the migration date after being locked, please contact ÃÛ¶¹ÊÓƵ for assistance.

And then one day before the migration ÃÛ¶¹ÊÓƵ will send system admins to the system admin console to send the email to the user. So they are encouraged to do the same for their users as well.

Okay now on the migration start date.

So the migration start date is scheduled for the end of the migration. So the migration begins at midnight on the migration start date.

And it depends on which time zone your subscription is.

And I’ll cover this a little bit more in a later slide. ÃÛ¶¹ÊÓƵ will migrate admins first automatically.

And depending on the number of users in your subscription and whether SSO is configured, there will be two types of user migrations.

If subscription has less than 75 users, and without SSO, they will be automatically migrated. No actions needed.

If your subscription has more than 75 users, regardless of SSO, or having SSO configured, regardless of the number of users, you will have to have more than 75 users. But if your subscription has less than 75 users, regardless of SSO, or having SSO configured, regardless of the number of users, you’ll be directed to self service migration.

And this process will review in more detail.

the admin console but please do not add existing users to market or engage. That’s what the user migration is for. I’m noting this because especially self-service migration can take up to 30 days complete, and we don’t want this to happen. I mean, we don’t want the admins to add users.

Each migrated user will receive an e-mail from ÃÛ¶¹ÊÓƵ on how to sign in with ÃÛ¶¹ÊÓƵ identity upon completion, and this invitation needs to be accepted by clicking a link in an e-mail. Sorry, I did bounce it a little too fast here. For automated migration, ÃÛ¶¹ÊÓƵ executes it from start to finish, and there is no action required as mentioned.

But for self-service, admin is required to confirm completion in the migration console by clicking a button. Other than that, there are no differences. The migration complete banner will be displayed to admins in my marketer page and the migration console goes away. Systems and product admins will receive user migration complete e-mail as well. From this point on, user migration are performed in admin console only.

The support migration will follow user migration, but only after all the subscription in ÃÛ¶¹ÊÓƵ all have been migrated. There are confusions out there as to when to start using the new support portal. I just wanted to call out the timing when the support migration can start for your organization and subscription. But the detailed discussion about the support migration is out of scope of today’s session. Another team is managing the project and I’m not best equipped to discuss this topic. But when the transition happens, the support admins will be directed to the new support portal from the existing support case portal on the Marketing Nation Community. Now we’re going to deep dive into four key areas of user migration.

Migration console. When the user migration is scheduled, all marketer engaged administrators will gain access to migration console, and you can find it in the admin section under integration.

They will access the pre-migration tab.

When user migration begins though, the pre-migration tab will no longer be available if it’s automatic migration, automated migration, then this migration console under integration will disappear. Admins will see a banner indicating the status of migration completion on the my marketer page. For self-service migrations, admins will gain access to the self-service migration tool, consisting of migration status and the user migration tab in the migration console. A banner also appears on the my marketer page, alerting admins that the user migration has started, and directing them to go to the migration console to execute.

When the migration is scheduled, just wanted to quickly show you what the admins will see, is this banner upon logging in to my marketer on their my marketer page. It has the days to a days countdown to the start date, and then link to pre-migration console. As I mentioned, admins will also receive e-mail notification with the subject line upcoming migration of existing users to the admin console for ÃÛ¶¹ÊÓƵ marketer engage with a prefix of your subscription. Then we’ve been talking about you can modify or admins can modify user migration start date that’s defaulted on the pre-migration console. I’m not sure if you can see it on your screen very well, but we will distribute this deck after, and this screen is where you see when the migration is scheduled. When you click on this edit button, you can select a new start date. The date should be no later than 30 days or no sooner than eight days from that date that you’re trying to make a change.

This is just a repeat of what I mentioned earlier, but due to the complexity of the migration, date changes are restricted to no more than 30 days beyond the scheduled date and it cannot be rescheduled within a week of scheduled migration date on the pre-migration console.

Most of you probably have gone through e-mail verification by now, but this is such an important piece for users to be migrated without losing their historical user data. We use a data such as an in-app guide progress, and the community profiles and contribution made in marketing nations. I think it’s worth covering this topic even as a quick refresher here. Again, e-mail verification is required for all users, but not the API only users for migrating to ÃÛ¶¹ÊÓƵ Identity. ÃÛ¶¹ÊÓƵ activates e-mail verification when it’s time for your subscription, again, it might have already happened to yours most likely. When it’s activated, admins will see an in-app message that e-mail verification has been turned on. Users will receive an e-mail verification request e-mail with a link that stays valid for three days. Let’s say the user didn’t see the e-mail, and over three days after it was sent, link is no longer valid, and you need this e-mail sent again to the user. Admins can resend the request by selecting verified users record in users enroll section in your admin section of the product, and click Verify e-mail button. Or better yet, users themselves can send it to themselves by going to Admin, My Account, Account Settings, and there they will see e-mail status, I’m verified, and next to it, there’s a link to resend the verification. Just to note that an active user session is required for e-mail verification success, so users will need to sign into Marketo subscription using their identity provider URL first.

Here comes the scheduled migration date. Do you know when it will start? It depends on which time zone your subscriptions is in. In the US time zone, it begins at midnight of the Pacific time, and if subscriptions are not in the US time zone, then it begins at midnight of the subscription specified time zone.

How about what changes the user migration brings? I’ve been repeating myself about these, but here they are again. No more user management in Marketo engaged. This includes user expiration feature that you may have been using, but this feature is not available on admin console. The users with an expiration date in the future on the date of a migration will be migrated, and their expiration date will be grayed out after migration.

They’ll need to be manually removed on admin console on the desired date after migration. The system admins manage products and other ÃÛ¶¹ÊÓƵ products, if any, on admin console. ÃÛ¶¹ÊÓƵ product admins will manage user access to the product on admin console, and users will need to sign into Marketo engaged with ÃÛ¶¹ÊÓƵ ID. Things that don’t change are how you manage all other functionalities within the Marketo engaged application itself, like role management, permission, API only, user management, and workspace management, and other functionalities.

What happens when user migration begins is that ÃÛ¶¹ÊÓƵ will automatically migrate all Marketo engaged admins with verified e-mail first, and up to the subscriptions admin console as product admin, grant an ÃÛ¶¹ÊÓƵ product admin role within the Marketo engaged application, and along with any other roles that they previously had, entitled to the Marketo engaged subscription with ÃÛ¶¹ÊÓƵ ID, and send two e-mails. One is about product admin assignment, and the other is about Marketo engaged product entitlement, with that subject line that you see on the slide.

After ÃÛ¶¹ÊÓƵ means are migrated, there will be two migration path based on the number of users and SSO criterion. We covered most of it on the migration console slide previously, but I wanted to show you the banner that ÃÛ¶¹ÊÓƵ will see for self-service migration mainly here. The user migration has started, proceed to the migration console to complete migration, with a link right here to the migration console. I think somehow the screenshot is covering some of the text there. I didn’t realize it was okay yesterday when I checked, but it just basically says admins are responsible for completing the user migration using the self-service migration tool within 30 days. In case you couldn’t see part of it.

What happens during user migration to ÃÛ¶¹ÊÓƵ IDs? User migration occurs concurrently, but each eligible user is migrated independently from one another. This means that if one user’s migration is taking long or stuck, migrations for other users will continue. If a user logged into Marketo during user migration, can lose access to up to one minute, and when he or she is successfully migrated, this person will receive an e-mail on how to sign in to Marketo Engage with an ÃÛ¶¹ÊÓƵ ID as you see here with the screenshot. This invitation again needs to be accepted via the button link in the e-mail subject line with action required, important change in how you sign into Marketo Engage.

In rare event, if a user migration failure occurs, and when we say this, we’re talking about a single user migration failure for one person, ÃÛ¶¹ÊÓƵ will continue to process migration of other eligible users. Not the whole thing will stop. An e-mail notification is sent to all admins of the subscription with a subject, migration of existing users pending issue resolution for ÃÛ¶¹ÊÓƵ Marketo Engage. No action is required by an admin at this time. ÃÛ¶¹ÊÓƵ engineering will also be notified and be working to address the issue as soon as possible. If this user is logged into Marketo Engage during migration, he or she could lose access for up to two minutes while ÃÛ¶¹ÊÓƵ attempts to migrate this user again. But this user can continue to access the product with their Marketo identity.

It’s not that if the user migration fails, then the user can’t access the product, but just rather use existing login credential until such time that the user migration is successfully completed for this user. Once that happens, this user will receive an e-mail invitation to sign into Marketo Engage with an ÃÛ¶¹ÊÓƵ ID like other successfully migrated users on the first try.

Now for self-service migration, there will be two tabs that appears in the migration console. The migration status tab basically allows you to monitor status, how many days remaining out of the 30 days from the start of the migration to complete self-service migration, and progress of a user e-mail verification prerequisites. Here’s the percentage, and then there’s also, you can see the actual status and how many skipped, etc. Users migration and activation status, how many have been migrated percentage, and if there is some failure, you’ll see it here, and completion of the subscription migration. During self-service migration, you’ll see a status as in progress. But when all users e-mail subscriptions are accounted for, meaning either migrated or skipped, then this complete migration button will appear.

One of the admins is required to confirm user migration is complete when the admin is ready to do so for that subscription. This will finalize the migration and remove the migration console from the admin section of the product. The other tab, user migration tab, allows you to act on trailing verification e-mail via the verify e-mail button, and then you’ll get the confirmation like this. Skipping users who can or shouldn’t be migrated because the person left the company, can’t verify e-mail address, whatever the reason, you can use this skip migration button. It’s grayed out, but I hope that you can see it says migrate now. This button allows you to select a set of users and migrate them on demand. The next two that also grayed out, but the scheduled migration button allows you to select several users to migrate on a specific date.

Lastly, migrate all users button, will allow you to migrate all eligible users on demand, and you do not need to select the users. You’ll just automatically pick up every single eligible users and migrate at once.

That was the details of some of the key areas of user migration. We have helpful resources here. When you get this deck, you should be able to open this hyperlink by right-clicking each one of them. This will take you to a documentation that ÃÛ¶¹ÊÓƵ provides in the subject. First one is ÃÛ¶¹ÊÓƵ Identity Management quick guide about migrating to ÃÛ¶¹ÊÓƵ Identity.

What I presented here today are discussed, explained in more detail in this migrating to ÃÛ¶¹ÊÓƵ Identity and for understanding marketer subscription and user migration to the ÃÛ¶¹ÊÓƵ Admin Console.

There’s another useful resource called User Setup Checklist and ÃÛ¶¹ÊÓƵ Experience Cloud Interface Overview. I highly recommend that you check them out.