Hi Sohini,

Yes — both are valid gaps in the current Microsoft Active Directory v2 Spoke.

For Create User, ServiceNow currently derives the UPN as:

<username>@<DNS-domain-name>

So with AD DNS domain ABCcorp.com, OOB creation gives user@ABCcorp.com. There is no exposed input to override it with the alternate suffix @ABCcom.

PasswordNeverExpires is also not exposed by the OOB Create/Update User actions. Microsoft AD itself supports both attributes through PowerShell, so the limitation is the ServiceNow spoke action, not AD.

Recommended implementation

Do not modify the Store spoke/OOB action directly. Keep the OOB Create User action, then immediately call a custom IntegrationHub action.

Create:

Custom Action: Set AD User Properties

Inputs:

sam_account_name    String
user_principal_name String
password_never_expires Boolean

Add a PowerShell step using the same AD v2 Connection/Credential Alias and MID Server. ServiceNow supports PowerShell steps with input variables passed from the action.

PowerShell:

Import-Module ActiveDirectory

Set-ADUser `
    -Identity $sam_account_name `
    -UserPrincipalName $user_principal_name `
    -PasswordNeverExpires $password_never_expires `
    -ErrorAction Stop

Map the PowerShell step input variables:

sam_account_name
    = Action Input → sam_account_name

user_principal_name
    = Action Input → user_principal_name

password_never_expires
    = Action Input → password_never_expires

Then your flow becomes:

1. Microsoft AD v2 → Create User

2. Custom → Set AD User Properties
      sam_account_name    = testing
      user_principal_name = testing@ABCcom
      password_never_expires = true

Set-ADUser natively supports both -UserPrincipalName and -PasswordNeverExpires. PasswordNeverExpires sets the underlying ADS_UF_DONT_EXPIRE_PASSWD flag in userAccountControl.

One important constraint: if your Create User logic sets Change password at next logon = true, you cannot simultaneously set PasswordNeverExpires = true. Microsoft explicitly treats those options as incompatible.

So I would implement it as a small post-create custom action rather than cloning the whole AD v2 Create User action. It is cleaner and avoids maintaining a fork of the ServiceNow Store spoke.

Thanks,

Saurabh