Hello @VenkateshwarRaoG.85600 (Customer)​ Thank you for posting on our Community page!

You are asking why the Okta Workflow creates the user account in Active Directory successfully, but no successful AD account creation event appears in the Okta System Log.

The account creation event is usually not logged under a generic "user created" event type. Provisioning to Active Directory is recorded as an application-level event tied to the AD app instance, and it can be missed by a search that only looks for user lifecycle events. The Workflow execution history is also a separate record from the System Log.

Root Cause: Okta records the AD account push as an application provisioning event (for example, a app.user_management event) with the AD application as the target, not as a standard user.lifecycle.create event on the user. Searches that filter only on the new user's login or on lifecycle create events will not return it.

Solution: Follow these steps to locate the successful AD creation record:

1. Navigate to Reports → System Log in the Okta Admin Console.
2. Filter the log with the query target.displayName eq "<your AD application name>" and eventType sw "app.user_management", then add a second filter on the user's login or target.alternateId if the results are too broad.
3. Review the events with an outcome of SUCCESS. Open the event and confirm the target user and the AD application in the Target section.
4. Check the Workflow's execution history under the Workflow's Flow Logs to confirm the Create User step completed and to view its returned output, including the AD account identifier.
5. Verify the account directly in Active Directory (Active Directory Users and Computers, under the expected OU) and confirm the AD Agent is running on the server that performs the push.
6. Search for failed events with outcome.result eq "FAILURE" for the same AD application if no success event appears. A failure in the same time window explains the missing success record.

If the user is not created in AD after these checks, confirm the group-to-application assignment and the AD app's provisioning settings (To App → Create Users enabled) under the application's Provisioning tab.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.

Hello @GayeongS.93038 (Customer)​ Thank you for posting on our Community page!

You are asking about the recommended approach for configuring Okta provisioning queries when your source data is spread across multiple normalized tables (employee master, department, dual-position, dispatch, and a separate contractor interface) rather than a single flat table. Specifically, you want to know whether to use inline SQL JOINs/UNIONs or wrap them in views or stored procedures, and how to handle combining multiple sources into a single provisioning flow.

Solution: Both approaches are technically viable, but stored procedures or database views are the recommended pattern for production environments because they abstract complexity, improve maintainability, and simplify troubleshooting.

Inline JOINs vs. Views/Stored Procedures:

1. Use a database view or stored procedure if your query involves:

• Multiple JOINs across normalized tables
• Complex business logic (e.g., determining primary vs. secondary positions)
• Conditional logic to filter or transform data
• Need to reuse the same query across multiple Okta provisioning operations (Get Users, Create, Update, Deactivate)

1. Advantages: Easier to test independently, simpler to modify without touching Okta configuration, cleaner audit trail, and your DBA can optimize the query at the database layer.
2. Inline SQL is acceptable only if your query is simple (a single table or one straightforward JOIN) and unlikely to change. For your multi-table scenario, inline SQL becomes difficult to maintain and debug.

Combining Multiple Sources (Employees + Contractors):

For combining employees and contractors into a single provisioning flow, use one of these patterns:

• Single UNION view (recommended): Create a database view that UNIONs the employee and contractor result sets, ensuring both return the same column structure and naming. This keeps Okta configuration simple — you point to one view for Get Users, Create, Update, and Deactivate. The view handles the complexity of merging schemas.

Example structure:

SELECT emp_id AS user_id, emp_name AS name, emp_email AS email, 'EMPLOYEE' AS source_type FROM employee_master

UNION

SELECT contractor_id AS user_id, contractor_name AS name, contractor_email AS email, 'CONTRACTOR' AS source_type FROM contractor_interface

• Separate app instances (if sources require different provisioning rules): If employees and contractors have fundamentally different provisioning lifecycles, deactivation rules, or attribute mappings, configure two separate Okta provisioning app instances — one pointing to the employee view and one to the contractor interface. This gives you independent control but requires managing two configurations.
• Avoid mixing inline JOINs and UNIONs in Okta: Do not attempt to write the UNION or JOIN logic directly in Okta's SQL field. Instead, encapsulate it in a view or stored procedure and reference that from Okta.

Best Practice Checklist:

• Create a dedicated database view or stored procedure that handles all normalization and returns a flat result set matching Okta's expected schema.
• Test the view independently before configuring it in Okta.
• Ensure the view returns consistent column names and data types for all provisioning operations (Get Users, Create, Update, Deactivate).
• For dual-source scenarios (employees + contractors), use a UNION view unless the sources have incompatible provisioning rules.
• Document the view logic and any business rules (e.g., how dual positions are resolved) so future maintainers understand the data flow.

This approach is common in production environments because it separates data transformation (database layer) from identity provisioning (Okta layer), making both easier to troubleshoot and evolve independently.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.

Hello @PhilG.96012 (SPS Commerce)​ Thank you for posting on our Community page!

At this time there no formal "end-of-life" date for the v1 Request Types, the current documentation establishes the v2 model as the strategic standard.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.