I have used it for ~2 years.
If the requirements can be met through product configuration, then issues don't arise as often. Customizations (depending on complexity) can be problematic at times.
Transporting change labels across environments can be confusing. It should be noted that the content contained in change labels should be documented right from the beginning of the project and all team members should be on the same page.
It's more about getting used to the correct way of working with the product rather than issues with deployment.
I have not encountered any stability issues.
We implemented the tool in an environment with roughly 35,000 active employees and over 2,000 service accounts. A few things I noted were:
- The web portal (IT Shop) tends to get a bit slow loading information for certain roles that have access to lookup all employees.
- The admin tools can also get a bit slow while loading too much information at once. For example: Loading user account information under the Active Directory tab in Manager can take a long time.
- We had various rules defined in our scripts for central account generation. One of those included a check in a history table to avoid granting a user name which has already been used in the past thus avoiding collisions. This caused our contractor account requests through the web portal to become extremely slow. Submitting a user account request from the IT Shop could take up to four minutes at times. We had all necessary columns indexed and the code to generate CentralAccount was written by the vendor team itself but the slowness could not be tackled.
- There was always a direct relation between the slowness we faced and the number of employees the environment managed. For example: Account requests used to take roughly 20 seconds in our development environment which had roughly 15k users and almost 25k entries in the history table we maintained to avoid username collision. In our production environment, it took way longer since the number of employees increased to ~35k and entries in our history table exceeded 150k records.
Customer Service:
Customer service was just average during implementation phase.
Technical Support:
Technical support is decent overall. However, some SRs took way too much time to resolve for the value they provided.
Some escalation engineers are very knowledgeable and troubleshooting sessions with them can be really worthwhile and informative.
We previously used legacy scripts with Microsoft FIM as the backend. FIM was too old and not user friendly at all. It was ancient in terms of IDAM and there were far better products with a lot more capabilities.
Setup was straightforward. Initial JobService configurations ends up being a bit confusing.
It was a hybrid implementation: We had an in-house team and a vendor team during the time of development for the first phase of the project. The second phase was done purely in-house.
The vendor team was not good. It was just average. There were a lot of times when we felt communication was lacking from the vendor side and at times, there were mistakes in the implementation, also. We recognized some errors long after the product had gone live. Overall quality delivered during development was not up to the mark. Average experience during the first phase with the vendor caused us to stick to a complete in-house implementation for the second phase.
Vendor teams (at least in the US) should be trained more about the tool's capabilities. I have heard that European vendor teams are much better with a lot more knowledge about the product.
Before choosing this solution we also evaluated TIM, OpenIAM, OIM, and SailPoint. All had week-long PoCs with us. We chose Q1IM (at the time, D1IM). SailPoint was a close second.
It is certainly a leading product in the IAM sphere.
