nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
- SolarWinds Academy
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Entra Provisioning of Custom Fields on User creation - Enterprise Applications integrations

timyal

Currently , only predefined set of system attributes, such as email, title, phone, manager, roles, name, site, and department are populated with the Entra user provisioning.

Provisioning custom fields would be valuable, especially for provisioning, catalog workflows, and automation. E.G. Workflow approvals based on company Directorate on the User profile.

Find more posts tagged with

Active

provisioning

custom field

Enterprise Application

entra

Status: Active

Comments

havens1515

I agree with all of this.

The entire implementation of the Entra integration just feels lazy. Because it is a "Process Integration", it is only available to the "main" service provider if you are using ESM. Which means that if you have an HR service provider, and new hire tickets go through that service provider, you cannot use this Entra "integration."

The fact that you have to match - 1 to 1 - a field in SolarWinds to a field in Entra means that you can't easily have multiple service requests for different things. Or, if you do, you have to use the same fields in both requests. And you have to remember which field was used in that request. (For example, there may be multiple requests with an "Employee" field, or even a "New Employee" field, or a "Manager" field. You need to know which of these fields were used in the "New Hire" request.)

The whole design of this integration is messy and difficult to actually use, in practice vs in theory.

I actually came here to create a similar request, addressing the things I mentioned here, but I'll just piggy back onto this one. (Unless they would prefer a separate request.)