What is your primary use case for Omada Identity Cloud?

We utilize self-service access request workflows. We faced a compliance issue when an employee from the Poland team ran a script that deactivated almost 400 accounts. Sometimes there will be a flaw. He ran the script and 400 users were automatically terminated. In our organization, we have a status in Omada Identity that defines users as active, inactive, or terminated. After this incident, many employees reported that they were not able to log into the system, mail, or access the internet. When we checked the identity status of the user, it was actually terminated. We initially thought HR had terminated these accounts for some reason, but that was not the case. The colleague from the Poland team ran a script that was not correct and removed everything. The development team of Omada Identity took care of everything and reactivated the users, resolving the issue. I assess the integration capabilities of Omada Identity with existing IT infrastructures positively. Most of our self-service requests are automated. If someone needs something and they raise it from the ITSSP self-service portal, it goes through automation and is done within 15 minutes, with the ticket closed automatically. We have a ticketing tool called BMC Remedy, and we raise the ticket from there, which is connected to Omada Identity. If a user needs something, the automation goes to Omada Identity and gives the resources or facilitates changes in job title, functional area, or location. After HR approval, it automatically changes. Everything is connected, and I evaluate the integration capabilities of Omada Identity with third-party tools and existing infrastructures positively. We use SAP, which is our first point of contact and integrated with Omada Identity, while Omada Identity is connected to Active Directory. Although this is primarily managed by the development team, we have a mini master in the SAP system containing details of employees. Once saved, the details sync with Omada Identity. When searching for an employee ID or name, we get all results including their email, first name, last name, SAP ID, and functional unit, and then it goes to Active Directory. These tools are linked very well. The risk-based approach of Omada Identity helps our organization manage potential security threats as Omada Identity is safe. It operates only on our intranet if configured perfectly. You cannot access Omada Identity's page from your computer unless you are connected to our company's VPN. If connected to an external network, you cannot access Omada Identity. The security is robust, and we have not faced any major threats such as phishing emails. We have a cybersecurity team that handles potential issues, but to my knowledge, Omada Identity is safe. The overall positive impacts and benefits I have seen since the deployment of Omada Identity are significant. The tool is impressive as every single detail of the user is actually available on Omada Identity. There is nothing else apart from Omada Identity where you can check the details in another application. This is a single application where you get everything about the employee, including their manager, identity owner, and every detail needed. Omada Identity is actually useful.

My use case for Omada Identity stems from my position as an Identity Access Management Engineer. I used it previously as a user for a few months, and after that, I became the administrator of the platform itself.

We use Omada Identity for managing 99% of our employees and non-employee identities. We also use it for provisioning to Active Directory and across 12 different SAP systems and two other application integrations.

Omada Identity is our platform for managing the entire lifecycle of user identities, including creating and assigning roles based on changing needs (dynamic roles and birth rates), and we'll soon be implementing access review workflows.

It is to get more standardization for our organization on everything related to identity, provisioning, and managing access. I am not working a lot within the tool myself because it is not my role.

We use Omada Identity for its intended purpose of identity governance administration and efficiency. We are a large retail company with a wide network of stores and a significant number of employees. Our primary focus, until now, has been on automating processes for various scenarios.

I am the functional manager. I use the solution for user access management.

We use Omada for identity and access management tasks. It is a great platform that manages everything related to user accounts, licenses, and access permissions. We integrate it with other services, so all our identity and access management activities are handled through Omada.

We are using it for identity governance.

The main purpose is to get services up and running for user management in the whole company and automate workflows. We have a pretty big team. We develop a lot of custom solutions. We mainly use it as a toolbox to get a baseline of the IAM platform. We are doing a lot of customization for data. Customization is the key. We are in an industry where we have a lot of regulations. Most of the regulatory IGA features that we use are mainly for auditing purposes. We do not use the whole suite for that.

We use Omada to onboard and delete employee accounts, set permissions, and handle access requests. Our company has around 650 to 700 users and seven IT team staff working with it regularly.

Our final goal is the entire process of identity management including provisioning, de-provisioning, roles-based access, review-based access, and things like that, but first, we needed to replace the old legacy system. That was successfully done last summer. The main business case was realizing a unique joined identity process because we have students and we have employees. We have external contractor employees, and we have partners who work for our organization and need digital or physical access to our environment. Because of that, Avans wants to use a single identity and an identity for life. If a student who once studied at Avans becomes a teacher or an ICT employee five or ten years later, he or she should have the same identity back with the same UPN or email address, so we have to guarantee an account for life. Because of the source systems, we know it is a student, which studies they do, and, for employees, we know which department they work for and if they are a teacher or non-teacher personnel and things like that. Based on all those attributes, we have business rules guiding them towards a set of rights. From the moment they agree on the standard basic rules, we get their accounts created. We allow them to have access to that particular account. After the account is created, group memberships are assigned. Through runbook script, Omada sets the right into our Azure Entra ID environment.

We use it primarily for identity management for provisioning accounts and permissions to Active Directory and Microsoft Azure. We use it for providing our students/teachers with different roles they are assigned within the organization. We want to make sure that someone who comes into our organization both as a student and as an employee, maybe an external employee, gets one account with a different role setup and not multiple accounts. We have various systems where our users are enrolled. For an employee, it is a HR system. For students, it is a system called Studielink, which is the Dutch body where students register the study that they will follow. Those systems have connections to our Omada system where their identities are compared and joined. If an identity already exists, an additional role is added to the existing account. Otherwise, a new account is added. People are assigned resources through group memberships automatically. They are assigned licenses. They are assigned, for instance, permission to enter certain buildings or to make reservations in the room system, and most importantly, because of the governance component that is present in Omada, when a student or an employee leaves our organization, their rights are revoked so that there are no people who are no longer a member of our system.

We use Omada Identity for identity management and access management for requesting mailboxes or user-based policies.

When we decided to implement Omada, our main goal was to establish it as our central identity management system. We wanted to be able to plan and automate our entire user and permission management process, including things like introducing business roles, access request workflows, and user lifecycle management. These are core functionalities for us. Moreover, consolidating access management systems is important to us. We're optimistic about its potential.

We used Omada Identity to control the entitlement catalog of most or all of the access rights in the company. The main use of the solution was to control the catalog that determines the possible accesses and who has them. That's the foundation to get control over the existing accesses.

We use it for identity management. Our source system is SAP SuccessFactors. It is a human resource assistant. We do imports there, and we have connections to other applications. For the suppliers that we have, we make partner identities. We also use it for resources. People can ask for resources through the Omada portal. As a resource owner, you can deny access to a resource. If someone no longer needs access to a resource, you can revoke the access. You can do a lot with it. It is a wonderful system.

In general, we use Omada Identity for managing the lifecycle of identity access. This includes onboarding new employees and granting them access to various resources within our company, such as File Share or Ship Insight, among others. Additionally, for organizational transfers, when employees change departments or switch to a subsidiary, we rely on the old identity lifecycle management for the workforce.

We use Omada to control access and identities throughout the employee lifecycle. Omada is deployed throughout the organization. We have about 16,000 active users. Around 30 people in our IT department use Omada daily, but roughly a hundred people have access to the solution.

Omada is used for identity access management. I previously worked as a database specialist but switched jobs when I switched companies. I joined this company because I connected personally with the company culture. As part of my new role, I received training on Omada Identity Cloud, which was being taught to new hires. During my first six months with the company, I worked from the Omada office, explicitly focusing on Kubernetes to gain a technical understanding of the system. Developing new solutions and processes within the system can be very challenging for our customers, and it often requires highly qualified professionals to assist with the process. This is why companies typically hire consultants when they need to change their systems. I started as a consultant and am now a full-time employee. As such, I can leverage my expertise to provide valuable guidance and support to our clients needing assistance with their systems. We have just under 3,000 users spread out across multiple locations in Denmark. Departments across the county can access the system from the cloud.

We wanted a solution that could help us make HR the master of identities. We wanted a solution that could take that data and direct it into all our other directories and Active Directory.

We use Omada Identity Cloud to onboard and offboard user accounts and manage permissions. We are using the cloud version.

My primary use cases of this solution are to manage the life cycle of identities, manage authorizations for applications, and the re-certification of authorizations.

Our clients use it to onboard apps for provisioning, not just collections. They use Omada for provisioning to business applications, such as SAP and PeopleSoft. They use ServiceNow as the front door to that but Omada is for their accounting and their HR business applications. It's mostly used for the governance piece, certification—GRC. Compliance is often what the issue is for our customers. They want to hurry up and get these products onboarded and set them up for provisioning for their business application, so they can meet whatever regulatory compliance controls they're trying to meet. We're an Omada partner/vendor. We implement both their on-prem and SaaS versions.

We are using Omada Identity Cloud, their SaaS version, as part of our identity and access management proposition towards our customers. We are an IT security company situated in the Netherlands. What we're trying to do: We give our customers guidance in their needs, aims, and goals regarding identity and access management. Therefore, we are the trusted partner for our customers in order to give them control over their identity and access management landscape, and we use Omada for this. We provide managed services for our clients. It is all cloud native. What we do, we say, "Dear customer: We can help bring your landscape under control from an identity and access management perspective. For that, we use Omada as our platform."