Your Hire to Retire - Position Management Data Template
Your Hire to Retire - Position Management Data Template
- Recommended attributes to collect for thorough analysis
- Key process activities to track for accurate discovery
- Extraction guidance specifically for Microsoft Dynamics 365 Human Resources
Hire to Retire - Position Management Attributes
| Name | Description | ||
|---|---|---|---|
| Activity Name ActivityName | The name of the specific event or task that occurred in the position management process. | ||
| Description This attribute describes a single step in the position's lifecycle, such as 'Position Request Initiated', 'Position Created In HR System', or 'Position Deactivated'. It forms the backbone of the process map, showing the sequence of events. Analyzing the Activity Name allows for the visualization of process flows, identification of deviations from the standard process, and calculation of transition times between different steps. It is fundamental for understanding what happened and in what order. Why it matters It defines the steps of the process, enabling the visualization of process maps and the analysis of process flow and variations. Where to get This attribute is derived from business events, status changes, or workflow history within Microsoft Dynamics 365 Human Resources. It is not a single field but is constructed based on the context of the data. Examples Position Request InitiatedPosition Request Approved By ManagerPosition Created In HR SystemPosition Attributes ModifiedPosition Closed | |||
| Event Time EventTime | The timestamp indicating when the activity occurred. | ||
| Description The Event Time, or timestamp, records the exact date and time an activity was completed. It is critical for ordering events chronologically and for calculating durations and cycle times. This attribute is used in almost every process mining analysis, from building the process map to calculating performance KPIs like 'Average Position Approval Cycle Time'. It helps pinpoint when delays occur and how long each step of the process takes. Why it matters This timestamp is essential for ordering events, calculating all time-based metrics, and discovering process bottlenecks. Where to get This information is typically found in system log tables or as 'CreatedDateTime' or 'ModifiedDateTime' fields associated with position and workflow records in Dynamics 365 HR. Examples 2023-04-15T09:00:00Z2023-04-15T14:35:10Z2023-04-18T11:21:05Z2023-05-02T16:45:00Z2024-01-10T10:00:00Z | |||
| Position ID PositionId | The unique identifier for a specific job position within the organization. | ||
| Description The Position ID serves as the primary case identifier, linking all activities and data points related to a single organizational position. This allows for end-to-end tracking of a position's entire lifecycle, from its creation and modifications to its eventual deactivation or closure. In process analysis, this ID is essential for reconstructing the journey of each position. It enables dashboards that monitor cycle times, identify bottlenecks in approvals, and analyze process variants from request to closure. Why it matters This is the core identifier that connects all related events into a single process case, making it possible to analyze the end-to-end position lifecycle. Where to get This is typically the HcmPosition.PositionId field in Microsoft Dynamics 365 Human Resources. It can be found in data entities like HcmPositionV2Entity. Examples POS001234MKT-0056FIN-SR-ANALYST-02HRBP-EAST-01IT-DEV-9876 | |||
| Cost Center CostCenter | The financial cost center to which the position's expenses are allocated. | ||
| Description The Cost Center is a key financial dimension that links a position to a specific budget or area of financial responsibility. Changes to this attribute are important to monitor. This attribute is critical for the 'Position Data Consistency Check' dashboard, which analyzes changes to key attributes after creation. It is also used to analyze position-related costs and budgets by different financial units. Why it matters It connects the position to financial data, enabling cost-related process analysis and monitoring data consistency. Where to get This is typically configured as a financial dimension on the position record. Consult the financial dimension setup in Dynamics 365. Examples CC-1001-FINCC-2500-ITCC-4510-SALESCC-7000-OPSCC-9002-HR | |||
| Department DepartmentName | The department to which the position belongs. | ||
| Description This attribute specifies the organizational department, such as 'Finance', 'Marketing', or 'IT', associated with the position. It is a primary dimension for filtering and aggregating process data. Analyzing by department is essential for the 'Departmental Position Throughput' dashboard. It helps compare process performance, identify department-specific bottlenecks, and understand hiring trends across different parts of the business. Why it matters It allows for process analysis to be segmented by business unit, helping to identify department-specific issues and compare performance. Where to get This information is part of the position details, typically stored on the HcmPositionDetail entity and linked to the operating unit dimension. Examples FinanceInformation TechnologySales and MarketingHuman ResourcesOperations | |||
| End Time EndTime | The timestamp indicating when the activity was completed. | ||
| Description EndTime marks the conclusion of an activity. The time elapsed between the StartTime and EndTime is the processing time for that specific activity. This attribute is essential for calculating activity-level durations and understanding where time is being spent within the process. For example, it helps determine how long a manager takes to approve a position request after it has been assigned to them. Why it matters It enables the calculation of activity processing times, which is fundamental for detailed performance and bottleneck analysis. Where to get This can be derived from subsequent event timestamps or from specific 'completion' fields in workflow logs within Dynamics 365 HR. Often, it must be inferred. Examples 2023-04-15T09:05:12Z2023-04-15T15:00:00Z2023-04-19T09:00:00Z2023-05-03T10:00:00Z2024-01-10T10:05:00Z | |||
| Job Title JobTitle | The title of the job associated with the position, such as 'Senior Accountant'. | ||
| Description The Job Title provides important context about the role and responsibilities of the position. It is different from the Position ID, as multiple positions can share the same job title. In analysis, this attribute allows for grouping and filtering by role type. It is useful for the 'Position Reclassification Trends' dashboard to see which types of jobs are being reclassified most often. Why it matters It adds crucial business context, allowing for analysis based on job role, level, or function. Where to get This information is linked from the 'Job' record associated with the Position. Look for it in entities like HcmPositionV2Entity or by joining to HcmJobEntity. Examples Senior Financial AnalystSoftware Engineer IIHR Business PartnerMarketing CoordinatorLogistics Manager | |||
| Position Status PositionStatus | The current or historical status of the position. | ||
| Description This attribute indicates the state of the position at a given point in time, such as 'Proposed', 'Active', 'Frozen', or 'Closed'. Status changes often correspond to activities in the process. Tracking status is crucial for understanding the position's journey and for dashboards like 'Position Compliance Review Status' and 'Stale and Underutilized Positions'. It provides a snapshot of the position's current state and helps validate the process flow. Why it matters It provides a clear state for each position, which is essential for filtering cases and understanding outcomes. Where to get Consult Microsoft Dynamics 365 Human Resources documentation. This is likely derived from status fields on the core Position record. Examples ProposedUnder ReviewActiveFrozenClosed | |||
| User Name UserName | The name or ID of the user who performed the activity. | ||
| Description This attribute identifies the employee or system user responsible for a given process step, such as the manager who approved a request or the HR specialist who created the position in the system. Analyzing by user helps identify training needs, compare performance across team members, and understand workload distribution. It is also key for compliance checks to ensure proper segregation of duties. Why it matters It provides accountability and allows for performance analysis by individual or team, which is crucial for resource management and training. Where to get Associated with workflow history or audit trail records in Dynamics 365 HR. It may be linked via a User ID from the HcmWorker entity. Examples John SmithJane DoeSYSTEMHRAdmin01MGR-FINANCE | |||
| Approval Cycle Time ApprovalCycleTime | The total time from when a position request is initiated until it is finally approved. | ||
| Description This calculated metric measures the duration from the 'Position Request Initiated' activity to the final approval activity, which could be 'Position Request Approved By HR'. It is a key performance indicator for the front-end of the position management process. This attribute directly populates the 'Position Approval Cycle Time' dashboard and KPI. It provides a high-level measure of the approval process's efficiency and helps track the impact of improvement initiatives over time. Why it matters It is a critical KPI that measures the efficiency of the entire approval process, directly highlighting delays in getting positions ready for creation. Where to get This is calculated at the case level by finding the timestamps for the start and end activities of the approval phase and computing the difference. Examples P3DT2H15MP10DP1DT12HP5DT6HP2W | |||
| Is Budget Approved IsBudgetApproved | A flag indicating if the budget for the position has been approved. | ||
| Description This boolean attribute is true if the 'Position Budget Approved' activity has occurred for a given position case. It helps in analyzing the process flow and identifying positions stuck waiting for budget. This attribute can be used to filter processes and analyze the 'Position Budget Approval Cycle Time' KPI more effectively. It helps to differentiate positions that have cleared the budget hurdle from those that have not, which is useful for bottleneck analysis. Why it matters It simplifies analysis by providing a clear flag for a critical milestone, helping to isolate and measure the budget approval stage. Where to get This is derived during data transformation by checking for the existence of the 'Position Budget Approved' activity within the case history. Examples truefalse | |||
| Is Rework IsRework | A flag indicating if an activity is part of a rework loop. | ||
| Description This boolean flag is set to true if an activity represents a step that is being repeated in the process, such as a re-approval after attributes were modified. It helps to quantify inefficient process loops. This attribute directly supports the 'Position Rework Analysis' dashboard and the 'Rework Rate on Position Creation' KPI. By flagging rework, analysts can easily filter for and measure the frequency and impact of process inefficiencies. Why it matters It explicitly identifies and quantifies process rework, which is a primary target for process improvement initiatives. Where to get This is calculated based on the sequence of activities for a case. For example, if 'Position Request Approved By Manager' occurs after 'Position Attributes Modified', it can be flagged as rework. Examples truefalse | |||
| Job Family JobFamily | A grouping of jobs with similar functions, such as 'Engineering' or 'Finance'. | ||
| Description Job Family is a classification that groups related job titles. For example, 'Software Engineer' and 'QA Engineer' might both fall under the 'Engineering' job family. This attribute is essential for the 'Position Reclassification Trends' dashboard, as it allows for a higher-level analysis of which job categories are changing most frequently. It provides a broader view than looking at individual job titles. Why it matters It allows for broader, category-based analysis of positions, which is useful for strategic workforce planning and trend analysis. Where to get This is part of the job setup in Dynamics 365 HR. Look for fields related to 'Job family' or 'Job function' on the HcmJobEntity. Examples EngineeringFinance & AccountingSalesHuman ResourcesProduct Management | |||
| Last Data Update LastDataUpdate | The timestamp of the most recent data refresh from the source system. | ||
| Description This attribute indicates when the data was last extracted from Microsoft Dynamics 365 Human Resources. It provides context for the freshness of the analysis. Displaying this information in dashboards assures users that they are viewing up-to-date information. It is a key piece of metadata for any process mining project. Why it matters It informs users about the timeliness of the data, which is crucial for making decisions based on the analysis. Where to get This timestamp is generated and stored during the data extraction, transformation, and loading (ETL) process. Examples 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| Location Location | The physical or geographical location of the position. | ||
| Description This attribute specifies where the position is based, which could be an office, city, or country. It is another important dimension for filtering and segmenting the process data. Location is used directly in the 'Departmental Position Throughput' dashboard to analyze staffing trends and process performance across different regions. It can help identify if position creation or approval processes are slower in certain locations. Why it matters It provides geographical context, allowing for analysis of process performance and trends across different locations. Where to get Consult Microsoft Dynamics 365 Human Resources documentation. This may be part of the position details or linked via the department or legal entity. Examples New York, USALondon, UKBerlin, GermanySingaporeRemote | |||
| Position Type PositionType | Classifies the position as full-time, part-time, temporary, etc. | ||
| Description This attribute categorizes the position based on its employment terms. This provides additional context for workforce analysis and planning. In process analysis, filtering by position type can reveal if certain types of positions have different process paths or longer cycle times. For example, temporary positions might have a faster, streamlined approval process compared to permanent, full-time positions. Why it matters It allows for analysis of how the process differs for various employment types, aiding in workforce planning and process optimization. Where to get This information is typically available on the position record in Dynamics 365 HR. Check entities like HcmPositionV2Entity for a relevant field. Examples Full-timePart-timeContractorInternTemporary | |||
| Processing Time ProcessingTime | The duration of time spent actively working on an activity. | ||
| Description Processing Time is the duration calculated between an activity's StartTime and EndTime. It represents the actual time spent on a task, excluding waiting time. This metric is fundamental for performance analysis and is used in dashboards like the 'Position Creation Bottleneck Monitor'. By summing the processing times of all activities, one can understand the total touch time for a position's lifecycle, which is a key component of efficiency analysis. Why it matters It measures the actual work duration of activities, helping to distinguish active work time from idle waiting time in bottleneck analysis. Where to get This is calculated during data transformation by subtracting the StartTime from the EndTime (EndTime - StartTime). Examples PT5M12SPT1H30MP2DT4H15MP0DPT8H | |||
| Rejection Reason RejectionReason | The reason provided when a position request is rejected. | ||
| Description When a position request is rejected by a manager or HR, a reason is often recorded. This could be due to budget constraints, incorrect information, or a change in strategy. This attribute is critical for calculating the 'Position Request Rejection Rate' KPI and understanding why rework occurs. Analyzing the most common rejection reasons helps identify upstream issues, such as poor request quality or unclear guidelines, that can be addressed to improve the process. Why it matters It provides direct insight into why requests fail, enabling targeted process improvements to reduce rework and rejection rates. Where to get Consult Microsoft Dynamics 365 Human Resources documentation. This is often captured in workflow comments or a dedicated reason code field upon rejection. Examples Budget Not AvailableDuplicate RequestIncorrect Job ProfileHiring FreezeStrategic Realignment | |||
| Requesting Manager RequestingManager | The manager who initiated the request for the position. | ||
| Description This attribute identifies the hiring manager or department head who started the process by requesting a new or backfill position. This information provides context on where the demand for positions originates. Analyzing by Requesting Manager can help identify patterns in request volume, approval rates, and request quality. It provides an additional layer of detail for understanding workload and process adherence. Why it matters It helps trace the origin of position demand and analyze process metrics from the perspective of the hiring manager. Where to get Consult Microsoft Dynamics 365 Human Resources documentation. This information would likely be captured in the workflow initiation data. Examples Robert JonesSusan MillerDavid ChenMaria GarciaPaul Williams | |||
| Source System SourceSystem | The system from which the data was extracted. | ||
| Description This attribute identifies the origin of the process data. For this view, it would typically be 'Microsoft Dynamics 365 Human Resources'. In environments with multiple systems, this field is crucial for data lineage and troubleshooting. It helps confirm that the data is coming from the expected source and can be used to filter analyses for specific systems. Why it matters It provides context about data origin, which is important for data governance and for analyses spanning multiple enterprise systems. Where to get This is a static value added during the data extraction and transformation process to label the dataset's origin. Examples Microsoft Dynamics 365 Human ResourcesD365 HRDynamicsHR | |||
Hire to Retire - Position Management Activities
| Activity | Description | ||
|---|---|---|---|
| Position Activated | Marks the point when a position becomes officially open and recruiting can begin. This event is inferred from a status field on the position record changing to 'Active' or a similar state. | ||
| Why it matters This is a critical milestone for measuring staffing readiness and the efficiency of the final setup stages. It is essential for the Average Time to Position Activation KPI. Where to get Inferred by tracking the timestamp when the status field, such as 'PositionStatus', on the position record is updated to 'Active' or 'Open'. Capture Based on the date the position's ActivationDate field is populated or a status field changes to 'Active'. Event type inferred | |||
| Position Closed | Represents the final archival of the position record, signifying the absolute end of its lifecycle. This event is inferred by a status change to 'Closed' or a similar terminal state. | ||
| Why it matters This is the terminal event for the process, allowing for complete end-to-end lifecycle analysis and helping to identify stale positions that should be closed. Where to get Inferred from a change in a status field to 'Closed' on the position record. This is less common than deactivation, as records are often kept for history. Capture Inferred from the timestamp when a status field is updated to 'Closed'. Event type inferred | |||
| Position Created In HR System | This event marks the official creation of the position record within Dynamics 365 HR. It is captured from the creation timestamp of the primary position record itself. | ||
| Why it matters A fundamental milestone that signifies the transition from request to an actual organizational entity. It is the endpoint for the Position Creation Lead Time KPI. Where to get From the 'CreatedDateTime' system field on the main position table, such as HcmPosition. Capture Extracted from the CreatedDateTime system field on the HcmPosition table. Event type explicit | |||
| Position Deactivated | The position is no longer active and is removed from the active organizational structure, often after being filled. This is inferred from a status change to 'Inactive' or a similar state. | ||
| Why it matters Marks a key step at the end of the position's active life. It's crucial for analyzing the Average Time to Position Deactivation and managing headcount accurately. Where to get Inferred from the timestamp when the 'RetirementDate' field is populated or a status field on the position record changes to 'Inactive'. Capture Based on the date the position's RetirementDate is set or a status field changes to 'Inactive'. Event type inferred | |||
| Position Request Approved By HR | Signifies the final approval from the Human Resources department before the position can be formally created. This is an explicit event logged upon completion of the HR approval task in the workflow system. | ||
| Why it matters This marks the end of the approval phase and is a critical milestone for measuring the overall Average Position Approval Cycle Time. Where to get Logged in the workflow history tables, such as WorkflowTrackingTable, when the HR representative completes their approval task. Capture Event is logged in the workflow history with a timestamp upon completion of the HR approval step. Event type explicit | |||
| Position Request Initiated | Marks the formal start of the position management lifecycle. This event is typically captured when a user submits a new position request through a dedicated form or workflow in Dynamics 365 HR. | ||
| Why it matters This is the starting point for measuring the entire position lifecycle, including crucial KPIs like Position Approval Cycle Time and Position Creation Lead Time. Where to get Captured from the creation timestamp of a position request record or the initiation record in the workflow history table, such as WorkflowTrackingStatusTable. Capture Event is recorded upon submission of a new position request workflow. Event type explicit | |||
| Hiring Process Started | Signifies the handover from position management to recruitment. This event is inferred when a new vacancy or recruitment project is created and linked to this specific position ID. | ||
| Why it matters Connects the position management process to its outcome, enabling analysis of the time between position activation and the start of actual hiring activities. Where to get Inferred by identifying the creation date of a record in the recruitment or vacancy tables, such as HcmRecruitingRequest, that references the Position ID. Capture Inferred by linking the PositionId to the creation of a corresponding record in the recruitment module. Event type inferred | |||
| Position Attributes Modified | Represents any change made to key attributes of a position, such as title or department, after its initial creation. This activity is typically inferred by tracking changes in the system's database log. | ||
| Why it matters High frequency of this activity can indicate poor data quality or process rework. It's essential for the Position Attribute Change Frequency and Rework Rate KPIs. Where to get Inferred from the SysDatabaseLog table if change tracking is enabled for the position table. Alternatively, it requires comparing historical snapshots of the position data. Capture Inferred by detecting update operations on key fields of the HcmPosition table via the database log. Event type inferred | |||
| Position Budget Approved | A key approval milestone confirming that the necessary funds are allocated for the new position. This is typically captured as a distinct approval step within the position creation workflow. | ||
| Why it matters Isolates the financial approval stage, allowing for analysis of delays related to budget allocation and supporting the Position Budget Approval Cycle Time KPI. Where to get Recorded in the workflow history tables, such as WorkflowTrackingTable, as a completed approval task, often assigned to a finance role. Capture Captured from the completion timestamp of the budget approval task in the workflow log. Event type explicit | |||
| Position Frozen | Indicates that a position has been temporarily put on hold, preventing any hiring activity. This is captured by inferring a status change on the position record to a 'Frozen' or 'On Hold' state. | ||
| Why it matters Tracks interruptions in the position lifecycle, which can impact staffing plans and budgets. It helps identify reasons for hiring delays. Where to get Inferred by tracking the timestamp when a status field on the position record is updated to 'Frozen' or a similar value. Capture Inferred from the timestamp of a status change to 'Frozen' or 'On Hold'. Event type inferred | |||
| Position Reclassified | A significant update where the position's fundamental classification, such as its job family or level, is changed. This is typically inferred from a change to the 'Job' field on the position record. | ||
| Why it matters Helps analyze organizational structure changes and the stability of job definitions. It is the key activity for the Position Reclassification Rate KPI. Where to get Inferred from a change in the 'JobId' field on the HcmPosition table, captured via the database log or by comparing record versions over time. Capture Inferred from a logged change to the job classification field on the position record. Event type inferred | |||
| Position Request Approved By Manager | Represents the completion of the first line of approval by the hiring manager. This event is recorded explicitly in the workflow history when the manager completes their assigned approval task. | ||
| Why it matters Pinpoints the duration of the initial approval step, helping to identify bottlenecks with specific managers or departments. Where to get Logged as a completed step in the workflow history tables, such as WorkflowTrackingTable, associated with the position request. Capture Captured from the completion timestamp of the manager approval step in the workflow log. Event type explicit | |||
| Position Request Rejected | Indicates that a position request has been denied at one of the approval stages. This event is explicitly captured in the workflow history when an approver selects the 'Reject' action. | ||
| Why it matters Highlights process failures and rework loops. Analyzing rejection reasons helps improve the quality of initial requests and supports the Position Request Rejection Rate KPI. Where to get Recorded as a 'Rejection' status in the workflow history tables, such as WorkflowTrackingStatusTable, for the specific position request. Capture Captured from the workflow log when an approver executes the rejection action. Event type explicit | |||
| Position Reviewed For Compliance | Indicates that a position has undergone a formal compliance check. This can be captured by a status change, a completed checklist task, or a custom field being updated. | ||
| Why it matters Crucial for monitoring adherence to regulatory and internal policies. This activity directly supports the Position Compliance Adherence Rate KPI. Where to get Likely inferred from a timestamped status field like 'ComplianceReviewStatus' or a boolean 'IsComplianceReviewed' field on the position record. Capture Inferred from the timestamp when a compliance status field is updated to 'Completed' or 'Reviewed'. Event type inferred | |||
Extraction Guides
Steps
- Navigate to the Data Management Workspace: Log in to Microsoft Dynamics 365 Human Resources. Use the main search bar to navigate to the 'Data management' workspace.
- Create a New Export Project: Within the workspace, select the 'Export' tile. On the 'Export' project page, click 'New' to create a new project. Provide a descriptive name, such as 'PositionManagement_EventLog_Export', and select a data format. For transformation purposes, 'CSV' is recommended.
- Add Data Entities to the Project: In your new project, click 'Add entity'. You will need to add several entities to capture the full position lifecycle. Add the following key entities one by one: 'HcmPositionV2', 'WorkflowTrackingStatusTable', and 'HcmRecruitingRequest'. If database logging is enabled for position changes, also add 'SysDatabaseLog'.
- Configure Entity Filters: For each entity, it is crucial to apply filters to limit the data scope. Select an entity, then click 'Filter'. For 'HcmPositionV2', filter by a specific date range using the 'CreatedDateTime' or 'ModifiedDateTime' fields. For 'WorkflowTrackingStatusTable', filter the 'CONTEXTTABLENAME' to include only position-related workflows.
- Select Fields for Each Entity: Ensure you are exporting all necessary fields for later transformation. For 'HcmPositionV2', include 'PositionId', 'CreatedDateTime', 'ActivationDate', 'RetirementDate', 'ModifiedDateTime', 'JobId', and 'DepartmentNumber'. For 'WorkflowTrackingStatusTable', include 'ContextRecId', 'WorkflowTrackingStatus', 'CreatedDateTime', and 'UserId'.
- Execute the Export Job: Once all entities, fields, and filters are configured, click 'Export' on the main project page. The system will create a data package containing separate files for each entity.
- Monitor and Download the Data Package: You can monitor the job's progress in the 'Job history' section. Once the job completes successfully, download the data package, which will be a compressed file.
- Extract and Transform the Data: Unzip the downloaded package. You will find separate CSV files for each entity. These files represent raw data, not the final event log. You must use an external script (e.g., using Python with pandas or PowerShell) to process these files.
- Implement Transformation Logic: Your script must perform the following actions:
- Load the 'HcmPositionV2.csv' file. From this file, generate the 'Position Created In HR System' event using 'PositionId' and 'CreatedDateTime'.
- Generate status change events ('Position Activated', 'Position Frozen', 'Position Deactivated', 'Position Closed') by interpreting status fields or date fields like 'ActivationDate' and 'RetirementDate' from 'HcmPositionV2.csv'.
- Load the 'WorkflowTrackingStatusTable.csv' file. Join this data with the position data using the record ID. From this, generate the workflow events: 'Position Request Initiated', 'Position Request Approved By Manager', 'Position Budget Approved', 'Position Request Approved By HR', and 'Position Request Rejected'. You will need to map the workflow status and step context to the correct Activity Name.
- If you exported 'SysDatabaseLog.csv', parse this file to generate 'Position Attributes Modified' and 'Position Reclassified' events based on changes to specific fields on the HcmPosition table.
- Load the 'HcmRecruitingRequest.csv' to generate the 'Hiring Process Started' event by finding when a recruiting request was created for a given position.
- Assemble the Final Event Log: The script should combine all generated events from the different sources into a single CSV file. This file must contain the required columns: 'PositionId', 'ActivityName', and 'EventTime', along with any recommended attributes you were able to map.
- Format for Upload: Ensure the final CSV file has headers matching the required attribute names and the 'EventTime' column is in a consistent timestamp format. The file is now ready for upload into the process mining tool.
Configuration
- Key Data Entities: The primary entities required for this extraction are:
HcmPositionV2: Contains core details about each position, including creation dates, activation dates, and attributes like job and department.WorkflowTrackingStatusTable: Provides the history of workflow instances, including submissions, approvals, and rejections. This is essential for tracking the approval process.HcmRecruitingRequest: Used to infer the 'Hiring Process Started' activity when a recruitment request is linked to a position.SysDatabaseLog: An optional but powerful entity for capturing detailed changes like 'Position Attributes Modified' and 'Position Reclassified'. Its use depends on database logging being pre-configured for the HcmPosition table.
- Date Range Filtering: It is highly recommended to apply a date range filter to the 'HcmPositionV2' entity based on the 'CreatedDateTime' field. A range of 6 to 12 months is often a good starting point to ensure a manageable data volume.
- Incremental Exports: For ongoing analysis, consider configuring the export project for incremental exports. This will only extract records that have changed since the last run, significantly reducing processing time.
- Prerequisites: The user running the export must have a security role with sufficient permissions to access the 'Data management' workspace and read access to all specified data entities. Roles like 'Data management administrator' or a custom role with specific entity privileges are typically required.
a Sample Query config
/*
This extraction uses the Dynamics 365 Data Management Framework. The 'query' is defined by configuring an export project via the user interface, not by running a script directly against the database.
A post-processing script is required to transform the output of this configuration into a final event log.
*/
-- Data Export Project Configuration --
Project Name: PositionManagement_EventLog_Export
Data Format: CSV
-- Entity 1: Positions --
Source Entity: HcmPositionV2
Fields to Export:
- PositionId
- CreatedDateTime (Used for 'Position Created In HR System' event)
- ActivationDate (Used for 'Position Activated' event)
- RetirementDate (Used for 'Position Deactivated' / 'Position Closed' event)
- ModifiedDateTime (Can be used for 'Position Attributes Modified' if SysDatabaseLog is not available)
- JobId (Used for 'Position Reclassified' event and 'JobTitle' attribute)
- DepartmentNumber (Used for 'DepartmentName' attribute)
- [Other fields for attributes like CostCenter, PositionStatus]
-- Entity 2: Workflow History --
Source Entity: WorkflowTrackingStatusTable
Fields to Export:
- ContextRecId (The record ID, used to link back to the HcmPosition record)
- ContextTableName (Filter this for 'HcmPosition')
- WorkflowTrackingStatus (Values like 'Submitted', 'Approved', 'Rejected')
- CreatedDateTime (Timestamp for the workflow event)
- UserId (The user who performed the action)
- [Workflow step name or ID field if available, to differentiate approval types]
-- Entity 3: Recruitment Requests --
Source Entity: HcmRecruitingRequest
Fields to Export:
- PositionId
- CreatedDateTime (Used for 'Hiring Process Started' event)
- RecruitingId
-- Entity 4: Database Change Log (Optional) --
Source Entity: SysDatabaseLog
Fields to Export:
- RefRecId (The record ID of the changed record)
- RefTableId (The table ID, filter for HcmPosition)
- CreatedDateTime (Timestamp of the change)
- [Fields indicating the old and new values, if available] Steps
- Prerequisite Confirmation: Before starting, verify that the 'Bring Your Own Database' (BYOD) feature is configured for your Microsoft Dynamics 365 Human Resources instance. Ensure that the required data entities are being exported to your Azure SQL Database. Key entities include:
HcmPositionV2,HcmPositionDetail,WorkflowTrackingStatusTable,HcmJob,OMOperatingUnit, andHcmRecruitingRequest. - Connect to Azure SQL Database: Use a SQL client tool, such as SQL Server Management Studio (SSMS) or Azure Data Studio, to establish a connection to the Azure SQL Database that serves as your BYOD destination.
- Identify Database Schema: Once connected, familiarize yourself with the database schema. The D365 HR data entities are replicated as tables. Note that table names in the BYOD database may not exactly match the entity names but are typically very similar.
- Load the SQL Query: Open a new query window in your SQL client and paste the complete SQL script provided in the 'query' section of this document.
- Customize Parameters: Modify the placeholder variables in the query. Set the
@[YourCompanyId]to the specific legal entity (e.g., 'USMF') you want to analyze. Adjust the date range in theWHEREclauses (e.g.,CREATEDDATETIME >= '2023-01-01') to limit the extraction to the desired time period. - Execute the Query: Run the complete SQL query against the BYOD database. The execution time will vary depending on the data volume and the selected date range.
- Review the Results: After the query finishes, inspect the output in the results pane of your SQL client. Verify that the columns
PositionId,ActivityName,EventTime, and others are populated as expected. - Export to CSV: Export the entire result set to a CSV file. Most SQL clients have a built-in feature to save results directly to a CSV file. For example, in SSMS, you can right-click the result grid and select 'Save Results As...'.
- Prepare for Upload: Ensure the exported CSV file has UTF-8 encoding. Confirm that the column headers exactly match the required attributes (
PositionId,ActivityName,EventTime, etc.) for a seamless upload into the process mining tool.
Configuration
- BYOD Data Entities: Ensure that all necessary data entities are published from Dynamics 365 HR to your BYOD instance. Critical entities for this process include those for positions, position details, workflow history, jobs, departments, and recruiting requests.
- Data Latency: Be aware that BYOD is a near real-time replication, not an instantaneous one. There might be a slight delay, from minutes to an hour, between a transaction occurring in D365 HR and the data appearing in the Azure SQL Database.
- Date Range Filtering: It is crucial to apply date filters to your query to manage performance and data volume. A typical starting point is a range of 3 to 6 months. Apply filters on creation or event timestamps within each
UNION ALLblock. - Company Filter: Always filter by the
DATAREAID(legal entity or company ID) to ensure you are analyzing data from the correct organizational unit. The provided query includes a placeholder@[YourCompanyId]for this purpose. - Prerequisites: This method requires an active Azure subscription, a configured BYOD instance, read permissions on the target Azure SQL Database, and a suitable SQL client tool for query execution.
- Custom Workflow Steps: The query uses common workflow step names for approvals like 'Approve position request'. If your organization uses custom names for these workflow steps, you will need to update the
CONTEXTvalues in the correspondingWHEREclauses.
a Sample Query sql
SELECT
p.POSITIONID AS PositionId,
'Position Request Initiated' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Initiated' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 1 -- Submitted
AND w.CONTEXT LIKE '%Create position request%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Request Approved By Manager' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Pending Budget' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 5 -- Approval
AND w.CONTEXT LIKE '%Manager approval%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Budget Approved' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Pending HR' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 5 -- Approval
AND w.CONTEXT LIKE '%Budget approval%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Request Approved By HR' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Approved' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 5 -- Approval
AND w.CONTEXT LIKE '%HR approval%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Request Rejected' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Rejected' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 3 -- Rejection
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Created In HR System' AS ActivityName,
p.CREATEDDATETIME AS EventTime,
p.CREATEDDATETIME AS EndTime,
p.CREATEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Created' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.DATAREAID = '[YourCompanyId]'
AND p.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Attributes Modified' AS ActivityName,
p.MODIFIEDDATETIME AS EventTime,
p.MODIFIEDDATETIME AS EndTime,
p.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Modified' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.MODIFIEDDATETIME > p.CREATEDDATETIME
AND p.DATAREAID = '[YourCompanyId]'
AND p.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Reviewed For Compliance' AS ActivityName,
pd.MODIFIEDDATETIME AS EventTime,
pd.MODIFIEDDATETIME AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Compliance Reviewed' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE pd.[YourComplianceStatusField] = 'Reviewed' -- This requires a custom field indicating compliance review
AND p.DATAREAID = '[YourCompanyId]'
AND pd.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Reclassified' AS ActivityName,
p.MODIFIEDDATETIME AS EventTime,
p.MODIFIEDDATETIME AS EndTime,
p.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Reclassified' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.MODIFIEDDATETIME > p.CREATEDDATETIME -- This is an inference. See known limitations.
AND p.DATAREAID = '[YourCompanyId]'
AND p.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Activated' AS ActivityName,
pd.VALIDFROM AS EventTime,
pd.VALIDFROM AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Active' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE pd.VALIDFROM >= '[StartDate]'
AND p.DATAREAID = '[YourCompanyId]'
UNION ALL
SELECT
hr.POSITIONID AS PositionId,
'Hiring Process Started' AS ActivityName,
hr.CREATEDDATETIME AS EventTime,
hr.CREATEDDATETIME AS EndTime,
hr.CREATEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Recruiting' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmRecruitingRequest hr
JOIN HcmPositionV2 p ON hr.POSITIONID = p.POSITIONID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE hr.DATAREAID = '[YourCompanyId]'
AND hr.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Frozen' AS ActivityName,
pd.MODIFIEDDATETIME AS EventTime, -- Assuming a status change triggers modification time
pd.MODIFIEDDATETIME AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Frozen' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.[YourPositionStatusField] = 'Frozen' -- Requires a dedicated status field on the position
AND p.DATAREAID = '[YourCompanyId]'
AND pd.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Deactivated' AS ActivityName,
pd.VALIDTO AS EventTime,
pd.VALIDTO AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Inactive' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE pd.VALIDTO < '2154-12-31' -- D365 often uses this far-future date for 'never expires'
AND pd.VALIDTO >= '[StartDate]'
AND p.DATAREAID = '[YourCompanyId]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Closed' AS ActivityName,
pd.MODIFIEDDATETIME AS EventTime, -- Assuming a status change triggers modification time
pd.MODIFIEDDATETIME AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Closed' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.[YourPositionStatusField] = 'Closed' -- Requires a dedicated status field on the position
AND p.DATAREAID = '[YourCompanyId]'
AND pd.MODIFIEDDATETIME >= '[StartDate]'