> Continuous Process Improvement > Hire to Retire Position Management > SAP SuccessFactors Employee Central > Data Template

Your Hire to Retire - Position Management Data Template

SAP SuccessFactors Employee Central

← Back to Improvement Guide

Hire to Retire - Position Management Attributes (20) Hire to Retire - Position Management Activities (13) Extraction Guides (3)

Your Hire to Retire - Position Management Data Template

This template provides a comprehensive guide for collecting the necessary data to analyze your Hire to Retire - Position Management process. It outlines essential attributes to collect, key activities to track, and practical guidance on data extraction. Use this resource to ensure you gather all the relevant information for a successful process mining initiative.

Recommended attributes to collect
Key activities to track
Extraction guidance for SAP SuccessFactors Employee Central

New to event logs? Learn how to create a process mining event log.

Download Template

Hire to Retire - Position Management Attributes

These are the recommended data fields to include in your event log for comprehensive Hire to Retire - Position Management analysis.

5 Required 5 Recommended 10 Optional

	Name	Description
	Activity Name ActivityName	The name of the business event that occurred at a specific point in time for a position.
Description This attribute describes a specific step or milestone in the position management lifecycle, such as 'Position Request Initiated', 'Position Created in HR System', or 'Position Deactivated'. Each activity represents a distinct event in the process. Analyzing the sequence and frequency of activities is the core of process mining. It allows for the visualization of the process map, identification of common and alternative process flows (variants), and pinpoints where delays or rework occur between steps. This is fundamental to understanding how the process actually operates. Why it matters It defines the steps in the process, allowing for the visualization of the process map and analysis of workflow, bottlenecks, and deviations. Where to get This is typically derived from event logs, status change records, or audit trails within the SAP SuccessFactors Employee Central system. It may require mapping from technical event codes or status transitions to user-friendly names. Examples Position Request InitiatedPosition Created in HR SystemPosition Attributes ModifiedPosition Deactivated
	Event Time EventTime	The timestamp indicating when a specific activity occurred.
Description Event Time records the exact date and time that an activity was executed or logged in the system. It provides the chronological order of events for each position's lifecycle. This timestamp is critical for all time-based analysis in process mining. It is used to calculate cycle times between activities, measure the duration of the entire process, identify bottlenecks by analyzing the time spent between steps, and trend performance over time. Without accurate timestamps, process analysis is not possible. Why it matters This attribute provides the chronological sequence of events, which is essential for calculating cycle times, discovering bottlenecks, and understanding process performance. Where to get This corresponds to the creation date or last modified date field associated with events or status changes in the position management audit logs or transaction records in SAP SuccessFactors. Examples 2023-04-15T09:00:00Z2023-04-15T14:30:15Z2023-05-01T11:20:00Z
	Position ID PositionId	The unique identifier for an organizational position, serving as the primary case identifier for the position management process.
Description The Position ID links all activities and data points related to a single organizational position. It allows for the end-to-end tracking of a position's entire lifecycle, from its initial request and creation to any modifications, reclassifications, and its eventual deactivation or closure. In process mining, each unique Position ID represents a single case. Analyzing processes through this identifier helps to understand the full journey of a position, measure total lifecycle times, and identify patterns or bottlenecks that affect positions from start to finish. It is the fundamental attribute for constructing the process map and calculating case-level KPIs. Why it matters This is the essential case identifier that connects all related events, making it possible to trace the complete lifecycle of a position and analyze its process flow. Where to get This identifier is a core element of the Position Management module in SAP SuccessFactors Employee Central, typically found in the Position object. Examples POS-1002345POS-1002346POS-2039871
	Last Data Update LastDataUpdateTime	The timestamp when the data was last refreshed or extracted from the source system.
Description This attribute indicates the last time the data for the process was updated in the process mining tool. It reflects the freshness of the data being analyzed. This is important for users to understand how current the analysis is and to manage expectations about the data's timeliness. It is a key piece of metadata for any dashboard or report. Why it matters It informs users about the freshness of the data, which is critical for ensuring that analyses and decisions are based on up-to-date information. Where to get This timestamp is generated by the data extraction and transformation pipeline at the time of execution. Examples 2023-10-27T08:00:00Z
	Source System SourceSystemId	The system from which the data was extracted.
Description This attribute identifies the source system where the event data originated. For this process, it will consistently be SAP SuccessFactors Employee Central. While it may seem redundant in a single-source model, it is a crucial field for data governance and maintaining context, especially in environments where data might be merged from multiple systems. It ensures clarity on data provenance. Why it matters It provides clear data provenance, which is essential for data governance, troubleshooting, and in scenarios involving multiple data sources. Where to get This is typically a static value added during the data transformation process to label the origin of the dataset. Examples SAP SuccessFactors Employee Central
	Approver ID ApproverId	The identifier of the manager or approver involved in an approval activity.
Description This attribute identifies the specific user who performed an approval step, such as 'Position Request Approved by Manager' or 'Position Request Approved by HR'. It is distinct from the general User ID as it specifically relates to approval tasks. Analyzing approval times by specific approvers can help identify individuals who may be bottlenecks in the process or who may approve things exceptionally quickly, indicating a best practice. It provides a more granular level of detail for analyzing the 'Departmental Approval Bottleneck' dashboard. Why it matters It allows for granular analysis of approval steps, helping to identify bottlenecks or high performers at the individual approver level. Where to get This is stored in the workflow or approval log data in SAP SuccessFactors, associated with the position request transaction. Examples m.joness.patele.williams
	Department DepartmentName	The name of the department to which the position belongs.
Description This attribute specifies the organizational department associated with the position, such as 'Finance', 'Sales', or 'Information Technology'. Department is a key dimension for comparative analysis. It allows you to benchmark process performance across different parts of the organization, for instance, by comparing position approval times between departments. This is essential for the 'Departmental Approval Bottleneck' dashboard and helps identify localized inefficiencies or best practices. Why it matters This enables performance comparison and bottleneck analysis across different business departments, helping to pinpoint area-specific issues. Where to get This is a standard attribute of the Position object in SAP SuccessFactors Employee Central. Examples FinanceSales - North AmericaResearch & Development
	Event End Time EventEndTime	The timestamp indicating when a specific activity was completed.
Description The Event End Time marks the completion of an activity. In many systems, an activity is recorded as a single point in time, in which case the End Time would be the same as the Start Time. However, for activities with a measurable duration, like an approval step that is actively being worked on, this field captures the completion moment. This attribute is essential for calculating the processing time of individual activities. It helps differentiate between waiting time (the gap between activities) and processing time (the duration of the activity itself), providing a more detailed view of process efficiency. Why it matters It enables the calculation of activity processing time, helping to distinguish between time spent working on a task and time spent waiting for the next step. Where to get This information may be available in audit logs or may need to be inferred. Often, it is the same as the StartTime for atomic events. Examples 2023-04-15T09:05:12Z2023-04-15T14:45:00Z2023-05-01T11:20:00Z
	Position Status PositionStatus	The status of the position at the time of the event.
Description This attribute indicates the state of the position, such as 'To Be Hired', 'Filled', 'Frozen', or 'Eliminated'. The status often changes as a result of specific activities in the process. Analyzing position status transitions over time is critical for understanding the position lifecycle and ensuring statuses are used consistently. The 'Position Status Transition Analysis' dashboard relies on this attribute to identify non-standard process flows and check for conformance to defined status models. It helps answer questions about how long positions remain in a particular state. Why it matters Tracking status changes is key to analyzing the position lifecycle, ensuring process conformance, and understanding how long positions stay in each state. Where to get This corresponds to the status field on the Position object in SAP SuccessFactors Employee Central. Examples To Be HiredFilledFrozenEliminated
	User ID UserId	The identifier of the user who performed the activity.
Description This attribute captures the unique ID of the employee or system user who executed a specific event, such as the manager who approved a position request or the HR administrator who created the position in the system. Analyzing by User ID is crucial for understanding workload distribution, identifying top performers, and detecting potential training needs. It also helps in resource analysis, compliance checks, and identifying activities that are performed by system or service accounts, indicating automation. Why it matters It helps attribute process activities to specific users, enabling workload analysis, performance measurement, and identification of automation. Where to get This information is typically found in 'Changed By' or 'User' fields within the audit logs or transaction data for the Position object in SAP SuccessFactors. Examples c.bakerj.smithSYSTEM_USER
	Budget Approval Status BudgetApprovalStatus	The status of the budget approval for the position request.
Description This attribute tracks the state of financial approval for a new position, with values like 'Pending', 'Approved', or 'Rejected'. It is specifically used to monitor the financial clearance step. This status is essential for calculating the 'Budget Approval Cycle Time' KPI and for the 'Position Budget Approval Duration' dashboard. It isolates the financial approval part of the process, allowing for focused analysis on delays caused by budget-related issues, which can be a significant bottleneck in position creation. Why it matters This directly supports the analysis of the budget approval stage, helping to identify and reduce delays in financial clearance for new positions. Where to get This information would be part of the position request workflow data in SAP SuccessFactors, likely as a status on a specific approval step. Examples Pending FinanceApprovedRejected
	Business Unit BusinessUnitName	The business unit associated with the position.
Description This attribute identifies the larger business division or unit that the position belongs to, which may be a level above the department. Similar to Department, Business Unit provides a dimension for high-level comparative analysis. It allows senior leaders to compare position management efficiency across major parts of the business, such as 'Consumer Products' vs. 'Enterprise Software'. Why it matters Enables high-level, cross-divisional process performance comparisons and helps align process metrics with strategic business units. Where to get This is a standard organizational structure attribute available on the Position object in SAP SuccessFactors. Examples Consumer ProductsEnterprise SoftwareGlobal Services
	Change Reason ChangeReason	The reason provided for a modification or reclassification of a position.
Description When a position is modified or reclassified, users often provide a reason for the change. This attribute captures that reason, such as 'Reorganization', 'Scope Change', or 'Annual Review'. This is a critical attribute for root cause analysis. It helps explain the 'why' behind process events like reclassifications or attribute modifications. Analyzing the most frequent change reasons can uncover underlying issues, such as unclear initial job descriptions or frequent organizational shifts, which is a key goal of the 'Position Reclassification Analysis' dashboard. Why it matters It provides the business context needed for root cause analysis, explaining why changes like reclassifications or modifications are occurring. Where to get This data is typically captured in a 'reason' or 'comment' field during transactions that modify the Position object in SAP SuccessFactors. Examples ReorganizationScope ChangeAnnual Review
	Country CountryCode	The country where the position is located.
Description This attribute specifies the country associated with the position's location. It is a key geographical dimension for analysis. Analyzing the process by country can reveal regional differences in efficiency, compliance requirements, or process execution. For example, position approval times might be significantly longer in one country due to local labor regulations or works council involvement. This helps in understanding and addressing location-specific process variations. Why it matters It allows for geographical analysis to identify regional variations in process performance, which may be influenced by local regulations or practices. Where to get This is part of the location information associated with the Position object in SAP SuccessFactors. Examples USADEUINDGBR
	Is First Time Right IsFirstTimeRight	A flag indicating if a position was created correctly the first time without immediate modifications.
Description This calculated attribute is a boolean (true/false) flag that checks if a 'Position Created in HR System' activity is followed by a 'Position Attributes Modified' activity within a short, predefined time window (e.g., 24 hours). If no modifications occur, it is marked as 'true'. This attribute directly supports the 'First-Time Right Creation %' KPI. It serves as a powerful measure of data quality and process effectiveness, highlighting cases where initial data entry was inaccurate or incomplete, leading to immediate rework. A low First Time Right rate indicates potential issues with training, system usability, or data validation rules. Why it matters This metric measures the quality of the position creation process, highlighting rework and data quality issues at the point of entry. Where to get This is a boolean flag calculated during data transformation by analyzing the sequence of events for each Position ID. Examples truefalse
	Job Family PositionJobFamily	The job family or functional area to which the position belongs.
Description The Job Family is a classification that groups related jobs together, such as 'Engineering', 'Finance', or 'Human Resources'. This provides a higher-level grouping than the specific Position Title. This attribute is essential for the 'Position Reclassification Analysis' dashboard. It allows analysts to track how frequently positions are reclassified between job families and to identify trends. For example, a high rate of reclassification from 'IT Support' to 'Cybersecurity' might indicate a strategic shift in the organization. Why it matters This attribute is crucial for analyzing reclassification trends and understanding organizational structure changes at a functional level. Where to get This is part of the job classification structure associated with the Position object in SAP SuccessFactors. Examples EngineeringFinanceHuman Resources
	Modified Attribute ModifiedAttribute	The specific attribute or field on the position that was changed.
Description When a 'Position Attributes Modified' activity occurs, this field specifies which attribute was changed, such as 'Department', 'Job Title', or 'Reports To'. This provides crucial detail for the 'Position Attribute Change Frequency' dashboard. Instead of just knowing that a change occurred, this allows for analysis of what is changing most frequently. A high volume of changes to a particular attribute might indicate that its definition is unclear or that the initial data provided is often incorrect for that specific field. Why it matters It adds critical detail to change events, allowing analysis to identify which specific data points are most volatile or error-prone. Where to get This information would come from detailed audit logs in SAP SuccessFactors that capture field-level changes, showing the old and new values. Examples DepartmentSupervisorCost CenterJob Title
	Position Approval Time PositionApprovalCycleTime	The total time from when a position request is initiated until it is approved by HR.
Description This is a calculated KPI that measures the duration of the entire approval phase for a new position. It is calculated at the case level by finding the time difference between the 'Position Request Initiated' event and the 'Position Request Approved by HR' event. This attribute directly measures the 'Avg Position Approval Time' KPI and is the primary metric for the 'Position Approval Cycle Time' dashboard. It provides a critical measure of organizational agility and the efficiency of the hiring front-end. Why it matters This is a key performance indicator that directly measures the efficiency of the position approval workflow, helping to track and reduce delays. Where to get This metric is calculated at the case level within the process mining platform or data transformation layer using the timestamps of the relevant activities. Examples P3D4H30MP10DP1DT12H
	Position Title PositionTitle	The official job title associated with the position.
Description This attribute holds the descriptive job title for the position, for example, 'Senior Financial Analyst' or 'Software Engineer II'. While not a primary driver of process flow, the position title provides important business context. It can be used to filter analyses for specific types of roles or to see if certain job titles are associated with longer creation cycle times or more frequent modifications. It adds a layer of business-friendly detail to the analysis. Why it matters It provides valuable business context, allowing for analysis to be filtered or segmented by specific job roles or levels. Where to get This is a standard attribute on the Position object in SAP SuccessFactors Employee Central, often linked to the Job Classification. Examples Senior Financial AnalystSoftware Engineer IIMarketing Coordinator
	Processing Time ProcessingTime	The duration of time spent actively working on an activity.
Description This attribute measures the time taken to complete a single activity, calculated as the difference between the Event End Time and the Event Time (Start Time). This is distinct from cycle time, which includes the waiting time between activities. Analyzing processing time helps identify which specific steps in the process are the most time-consuming to execute. This allows for targeted improvement efforts, such as simplifying a form, providing better training, or automating a task. For example, it can show if the 'Position Created in HR System' activity takes minutes or hours to complete. Why it matters It isolates the active work time for an activity, helping to pinpoint which specific tasks are most time-consuming, separate from any waiting time. Where to get This is calculated from the EventTime and EventEndTime fields during data transformation (ProcessingTime = EventEndTime - EventTime). Examples PT5M12SPT1H30MP1D

Required Recommended Optional

Hire to Retire - Position Management Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery.

6 Recommended 7 Optional

	Activity	Description
	Position Activated	This event signifies that the newly created position is made active and available for staffing or recruitment. This is typically inferred from a change in the position's status field to an 'Active' value.
Why it matters Activation is the final step before hiring can begin. Tracking the time from creation to activation helps identify delays in making positions ready for fulfillment. Where to get This is inferred by tracking changes to the 'Status' or 'Effective Status' field in the history of the Position MDF object. The timestamp of the change to 'Active' marks the event. Capture Inferred from a change in the position status field to 'Active'. Event type inferred
	Position Closed	This is the final event in a position's lifecycle, indicating it has been permanently closed or eliminated. This is typically inferred from a change in the position's status to a terminal value like 'Closed' or 'Eliminated'.
Why it matters This activity serves as the definitive end point for the process, allowing for accurate end-to-end cycle time analysis. It confirms that the position has been successfully retired. Where to get This is inferred by tracking changes to the 'Status' field in the history of the Position MDF object. The timestamp of the change to 'Closed' or 'Eliminated' marks the event. Capture Inferred from a change in position status to a terminal value. Event type inferred
	Position Created in HR System	This activity marks the official creation of the position record in SAP SuccessFactors Employee Central. It is captured explicitly from the audit trail or history of the Position MDF object, using the creation timestamp.
Why it matters This is a fundamental milestone that confirms the position officially exists. The 'Position Creation Cycle Time' KPI measures the duration from request initiation to this event, reflecting overall efficiency. Where to get This event is derived from the 'Created On' or 'Created Date' system field in the audit history of the Position Metadata Framework (MDF) object for the specific Position ID. Capture Extracted from the creation timestamp of the Position object record. Event type explicit
	Position Request Approved by HR	This activity signifies that the Human Resources department has approved the position request. It is a critical milestone, logged as an explicit completion step in the approval workflow.
Why it matters Final HR approval often concludes the main approval phase before budget allocation or system creation. Measuring the time to reach this step is vital for the 'Avg Position Approval Time' KPI. Where to get This is captured from the workflow logs associated with the position request. The event corresponds to the timestamp when the HR representative completes their assigned approval step. Capture Logged when the HR approver completes their step in the workflow. Event type explicit
	Position Request Initiated	This event marks the beginning of the position management process, when a user formally submits a request to create a new position. This is captured explicitly when a position creation workflow is triggered in SAP SuccessFactors.
Why it matters This is the primary start event for the process. Analyzing the time from this activity to others, like position approval or creation, is crucial for measuring overall process efficiency. Where to get This event is captured from the initiation of a workflow instance related to a position request. The data can be found in the workflow request tables, such as WfRequest, tied to the Position object. Capture Logged upon initiation of a new position workflow. Event type explicit
	Position Request Rejected	This event marks the rejection of a position request at any stage of the approval workflow. It is an explicit event logged by the workflow engine when an approver selects the 'reject' or 'send back' option.
Why it matters Rejections are critical process deviations that can indicate issues with the request data, budget, or justification. Analyzing rejection reasons helps improve the quality of future requests. Where to get This is captured from the workflow log data associated with the position request. It corresponds to a workflow step being completed with a 'rejected' status. Capture Logged when an approver rejects a step in the workflow. Event type explicit
	Position Attributes Modified	Represents any change made to the attributes of an existing position, such as its title, department, or cost center. This event is captured explicitly through the audit logs of the Position MDF object.
Why it matters Frequent modifications can indicate data quality issues or instability in organizational design. Analyzing these events helps measure the 'Position Attribute Mod Rate' and rework. Where to get These events are captured from the audit history of the Position MDF object. Each logged change with a 'last modified date' timestamp and user represents a modification activity. Capture Logged in the Position object's audit trail for any field change. Event type explicit
	Position Budget Approved	Indicates that the finance department or a budget holder has approved the financial aspects of the new position. This is typically an explicit step within the workflow, occurring after managerial and HR approvals.
Why it matters Delays in budget approval can significantly stall the hiring process. Isolating this activity helps in analyzing and optimizing the financial clearance stage of position management. Where to get This event is captured from the workflow logs for the position request, corresponding to the completion of the finance approval step. The approver is typically identified by a 'Finance' or 'Budget Holder' role. Capture Logged when the finance approver completes their step in the workflow. Event type explicit
	Position Deactivated	Represents the formal deactivation of a position, making it inactive and unavailable for use. This is inferred from a change in the position's status to 'Inactive' or 'Deactivated'.
Why it matters This is a key step in the position retirement process. Tracking the time from suspension to deactivation is crucial for measuring the 'Position Deactivation Lead Time' KPI. Where to get This is inferred from the audit history of the Position MDF object by identifying when the 'Status' or 'Effective Status' field is changed to 'Inactive'. Capture Inferred from a change in the position status field to 'Inactive'. Event type inferred
	Position Frozen/Suspended	This event indicates that a position has been temporarily put on hold and is not available for staffing. This is inferred from a change in the position's status field to a value like 'Frozen' or 'Suspended'.
Why it matters This activity often precedes deactivation or closure. Analyzing the duration a position remains frozen helps optimize workforce planning and headcount management. Where to get This is inferred by tracking changes to the 'Status' field in the history of the Position MDF object. The timestamp of the change to 'Frozen' or a similar value marks the event. Capture Inferred from a change in the position status field to 'Frozen'. Event type inferred
	Position Reclassified	This activity signifies a significant change to a position's core definition, such as a change in its job code or job family. This is inferred from a change to the 'Job Code' or 'Job Classification' field in the Position MDF object.
Why it matters High reclassification rates can indicate issues with initial job design or evolving business needs. Tracking this helps in analyzing organizational structure stability. Where to get This is inferred by monitoring the audit history of the Position MDF object for changes to key classification fields like 'jobCode'. The timestamp of such a change marks the event. Capture Inferred from a change in the 'jobCode' field of the Position object. Event type inferred
	Position Request Approved by Manager	Represents the completion of the first level of approval, typically by the hiring or line manager. This is an explicit event logged as a completed step in the position management workflow.
Why it matters Tracking manager approval times helps identify bottlenecks within specific departments or managerial levels. It is a key milestone for understanding the initial stages of the approval cycle. Where to get This is recorded as a step completion event within the workflow log data for the specific position request. It can be identified by the approver's role and the 'approved' status of the workflow step. Capture Logged when a user completes an approval step in the workflow. Event type explicit
	Position Reviewed for Compliance	Represents a periodic or event-driven review of a position to ensure it adheres to internal policies or external regulations. The capture mechanism for this event is highly dependent on customer-specific configurations, such as a custom workflow or MDF object.
Why it matters This activity is essential for monitoring and ensuring organizational compliance. It directly supports KPIs like 'Position Review Compliance %' and helps mitigate risks. Where to get Requires system analysis. This may be captured in a custom MDF object linked to the Position, via a custom workflow status update, or through an attachment log. Capture Dependent on custom implementation; likely a custom MDF object entry. Event type explicit

Recommended Optional

Extraction Guides

How to get your data from SAP SuccessFactors Employee Central

Steps

Navigate to Integration Center: Log in to your SAP SuccessFactors instance. Use the search bar to find and navigate to the Integration Center.
Create a New Integration: Click the "My Integrations" button. Select "Create" and then choose "More Integration Types".
Select Initial Settings:
- Integration Type: Choose "Scheduled".
- Source Type: Choose "SuccessFactors".
- Destination Type: Choose "SFTP".
- Format: Choose "CSV". Click "Create".
Configure the Core Entity: In the "Configure Fields" tab, search for and select the "Position" entity as the starting entity. Give your integration a descriptive name, like "ProcessMind Position Management Log".
Extract the 'Position Created' Event: This is the first event. Map the fields from the base Position entity. For the ActivityName field, use the "Set Fixed Value" option and enter "Position Created in HR System". Map PositionId to the code field and EventTime to the createdDate field.
Extract Workflow Events (Initiated, Approved, Rejected): To capture workflow events, you need to join the workflow data. Find the "positionWorkOrder" navigation property from the Position entity. From there, navigate to the wfRequestNav and then wfRequestSteps.
- Right-click the root node in the entity tree and select "Add Sibling Element".
- For this new element, navigate through the entities as described above.
- Create calculated fields for ActivityName like 'Position Request Initiated', 'Position Request Approved by Manager', etc. Use conditional logic based on the stepNum (step number) and status ('APPROVED', 'REJECTED') of the wfRequestSteps entity.
- Map EventTime to the completedOn field of the workflow step.
Extract Status Change Events (Activated, Deactivated, etc.): Many activities are derived from changes to the Position's effective-dated record.
- Add another sibling element, again starting from the Position entity.
- Navigate to the entity's history by selecting the record with the clock icon. This gives you access to changes over time.
- To detect a specific status change, you need to filter where the current record's status is, for example, 'A' (Active), and the previous record's status was different. Integration Center allows for some advanced filtering, but this may require a calculated field to evaluate.
- For each status change (Activated, Frozen, Deactivated, Closed), create a separate sibling element with the appropriate filters and a fixed value for ActivityName.
Extract Attribute Modification Events: Add another sibling element based on the Position's effective-dated history. Create a filter to include records where lastModifiedDateTime is within your reporting window but exclude records that represent the other specific events you already captured (like creation or specific status changes). This can be complex. Set the ActivityName to 'Position Attributes Modified'.
Configure Destination Settings: Go to the "Destination Settings" tab. Enter the details for your SFTP server, including Host Address, Port, Username, and authentication details. Specify the file name and output folder path.
Set Filtering and Sorting: In the "Filter" tab, create a time-based filter to limit the data extracted. It is highly recommended to filter on the lastModifiedDateTime of the Position object to perform delta loads. For the initial run, you might filter on createdDate. Sort the data by PositionId and then EventTime to ensure chronological order.
Schedule the Integration: Go to the "Scheduling" tab. Specify the frequency for the job to run, such as daily or weekly. This ensures your process mining data is kept up to date.
Review and Run: Review all settings in the final tab. You can run a test or set the integration to active. Once the job runs, the CSV file will be placed on the specified SFTP server, ready for upload to ProcessMind.

Configuration

Integration Type: Outbound Scheduled CSV. This creates a flat file on a recurring basis.
Starting Entity: The primary entity is Position. Most other required data is accessed by navigating to related entities from Position, such as its effective-dated history, workflow requests (wfRequestNav), and foundational objects.
Key Filters: Filtering by lastModifiedDateTime is critical for performance and creating manageable delta loads. For an initial historical load, filter by createdDate over a defined period, such as the last 6-12 months. Apply additional filters on company or businessUnit to limit the scope to relevant parts of the organization.
Paging: For large data volumes, ensure 'Server Side Pagination' is enabled in the destination settings to prevent timeouts. Adjust the page size as needed based on performance testing.
Prerequisites: You must have an SFTP server configured and accessible from your SuccessFactors instance. The user configuring the integration requires permissions to access Integration Center and OData API permissions for all entities being queried (Position, WfRequest, User, etc.).

a Sample Query config

/*
Integration Center is a UI-based tool. This script represents the logical configuration
of the entities, fields, and filters for each activity within a single integration job.
Each 'BLOCK' would be configured as a sibling element in the Integration Center UI.
*/

// BLOCK 1: Position Created in HR System
// This is the root element of the integration.
ENTITY: Position
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Created in HR System' (Fixed Value)
  EventTime = Position.createdDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.createdDate
  UserId = Position.createdBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  Position.createdDate >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 2: Workflow Events (Initiated, Approved, Rejected)
// This single block uses calculated columns to generate multiple event types.
ENTITY: Position -> positionWorkOrder -> wfRequestNav
FIELDS:
  PositionId = Position.code
  ActivityName = Calculated Field:
    IF wfRequestNav.wfRequestSteps.stepNum = 1 AND wfRequestNav.status = 'PENDING' THEN 'Position Request Initiated'
    IF wfRequestNav.wfRequestSteps.stepNum = [Manager Approval Step Number] AND wfRequestNav.wfRequestSteps.status = 'APPROVED' THEN 'Position Request Approved by Manager'
    IF wfRequestNav.wfRequestSteps.stepNum = [HR Approval Step Number] AND wfRequestNav.wfRequestSteps.status = 'APPROVED' THEN 'Position Request Approved by HR'
    IF wfRequestNav.wfRequestSteps.stepNum = [Budget Approval Step Number] AND wfRequestNav.wfRequestSteps.status = 'APPROVED' THEN 'Position Budget Approved'
    IF wfRequestNav.wfRequestSteps.status = 'REJECTED' THEN 'Position Request Rejected'
    ELSE null
  EventTime = wfRequestNav.wfRequestSteps.completedOn
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = wfRequestNav.wfRequestSteps.completedOn
  UserId = wfRequestNav.wfRequestSteps.processedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = wfRequestNav.wfRequestSteps.approverId
FILTERS:
  ActivityName IS NOT null
  wfRequestNav.wfRequestSteps.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 3: Position Activated
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Activated' (Fixed Value)
  EventTime = Position.effectiveStartDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.effectiveStartDate
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  Position.status = 'A' (Active)
  // This requires an advanced filter to check the status of the previous record, which can be complex in Integration Center.
  Position.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 4: Position Attributes Modified
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Attributes Modified' (Fixed Value)
  EventTime = Position.lastModifiedDateTime
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.lastModifiedDateTime
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  // This filter should exclude records that are purely status changes captured in other blocks.
  Position.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 5: Position Reclassified
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Reclassified' (Fixed Value)
  EventTime = Position.effectiveStartDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.effectiveStartDate
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  // Requires advanced filter to check if Position.jobCode has changed from the previous record.
  Position.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 6: Position Reviewed for Compliance
// This requires a custom MDF object or workflow configured by the customer.
ENTITY: Position -> cust_ComplianceReview.position
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Reviewed for Compliance' (Fixed Value)
  EventTime = cust_ComplianceReview.lastModifiedDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = cust_ComplianceReview.lastModifiedDate
  UserId = cust_ComplianceReview.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = cust_ComplianceReview.reviewerId
FILTERS:
  cust_ComplianceReview.lastModifiedDate >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 7: Position Frozen/Suspended
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Frozen/Suspended' (Fixed Value)
  EventTime = Position.effectiveStartDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.effectiveStartDate
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  Position.status = '[Your Frozen Status Code]'
  Position.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 8: Position Deactivated
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Deactivated' (Fixed Value)
  EventTime = Position.effectiveStartDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.effectiveStartDate
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  Position.status = 'I' (Inactive)
  Position.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 9: Position Closed
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Closed' (Fixed Value)
  EventTime = Position.effectiveStartDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.effectiveStartDate
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  Position.status = '[Your Closed/Eliminated Status Code]'
  Position.lastModifiedDateTime >= [Start Date]

Steps

Navigate to Integration Center: Log in to your SAP SuccessFactors instance. Use the search bar to find and navigate to the Integration Center.
Create a New Integration: Click the "My Integrations" button. Select "Create" and then choose "More Integration Types".
Select Initial Settings:
- Integration Type: Choose "Scheduled".
- Source Type: Choose "SuccessFactors".
- Destination Type: Choose "SFTP".
- Format: Choose "CSV". Click "Create".
Configure the Core Entity: In the "Configure Fields" tab, search for and select the "Position" entity as the starting entity. Give your integration a descriptive name, like "ProcessMind Position Management Log".
Extract the 'Position Created' Event: This is the first event. Map the fields from the base Position entity. For the ActivityName field, use the "Set Fixed Value" option and enter "Position Created in HR System". Map PositionId to the code field and EventTime to the createdDate field.
Extract Workflow Events (Initiated, Approved, Rejected): To capture workflow events, you need to join the workflow data. Find the "positionWorkOrder" navigation property from the Position entity. From there, navigate to the wfRequestNav and then wfRequestSteps.
- Right-click the root node in the entity tree and select "Add Sibling Element".
- For this new element, navigate through the entities as described above.
- Create calculated fields for ActivityName like 'Position Request Initiated', 'Position Request Approved by Manager', etc. Use conditional logic based on the stepNum (step number) and status ('APPROVED', 'REJECTED') of the wfRequestSteps entity.
- Map EventTime to the completedOn field of the workflow step.
Extract Status Change Events (Activated, Deactivated, etc.): Many activities are derived from changes to the Position's effective-dated record.
- Add another sibling element, again starting from the Position entity.
- Navigate to the entity's history by selecting the record with the clock icon. This gives you access to changes over time.
- To detect a specific status change, you need to filter where the current record's status is, for example, 'A' (Active), and the previous record's status was different. Integration Center allows for some advanced filtering, but this may require a calculated field to evaluate.
- For each status change (Activated, Frozen, Deactivated, Closed), create a separate sibling element with the appropriate filters and a fixed value for ActivityName.
Extract Attribute Modification Events: Add another sibling element based on the Position's effective-dated history. Create a filter to include records where lastModifiedDateTime is within your reporting window but exclude records that represent the other specific events you already captured (like creation or specific status changes). This can be complex. Set the ActivityName to 'Position Attributes Modified'.
Configure Destination Settings: Go to the "Destination Settings" tab. Enter the details for your SFTP server, including Host Address, Port, Username, and authentication details. Specify the file name and output folder path.
Set Filtering and Sorting: In the "Filter" tab, create a time-based filter to limit the data extracted. It is highly recommended to filter on the lastModifiedDateTime of the Position object to perform delta loads. For the initial run, you might filter on createdDate. Sort the data by PositionId and then EventTime to ensure chronological order.
Schedule the Integration: Go to the "Scheduling" tab. Specify the frequency for the job to run, such as daily or weekly. This ensures your process mining data is kept up to date.
Review and Run: Review all settings in the final tab. You can run a test or set the integration to active. Once the job runs, the CSV file will be placed on the specified SFTP server, ready for upload to ProcessMind.

Configuration

Integration Type: Outbound Scheduled CSV. This creates a flat file on a recurring basis.
Starting Entity: The primary entity is Position. Most other required data is accessed by navigating to related entities from Position, such as its effective-dated history, workflow requests (wfRequestNav), and foundational objects.
Key Filters: Filtering by lastModifiedDateTime is critical for performance and creating manageable delta loads. For an initial historical load, filter by createdDate over a defined period, such as the last 6-12 months. Apply additional filters on company or businessUnit to limit the scope to relevant parts of the organization.
Paging: For large data volumes, ensure 'Server Side Pagination' is enabled in the destination settings to prevent timeouts. Adjust the page size as needed based on performance testing.
Prerequisites: You must have an SFTP server configured and accessible from your SuccessFactors instance. The user configuring the integration requires permissions to access Integration Center and OData API permissions for all entities being queried (Position, WfRequest, User, etc.).

a Sample Query config

/*
Integration Center is a UI-based tool. This script represents the logical configuration
of the entities, fields, and filters for each activity within a single integration job.
Each 'BLOCK' would be configured as a sibling element in the Integration Center UI.
*/

// BLOCK 1: Position Created in HR System
// This is the root element of the integration.
ENTITY: Position
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Created in HR System' (Fixed Value)
  EventTime = Position.createdDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.createdDate
  UserId = Position.createdBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  Position.createdDate >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 2: Workflow Events (Initiated, Approved, Rejected)
// This single block uses calculated columns to generate multiple event types.
ENTITY: Position -> positionWorkOrder -> wfRequestNav
FIELDS:
  PositionId = Position.code
  ActivityName = Calculated Field:
    IF wfRequestNav.wfRequestSteps.stepNum = 1 AND wfRequestNav.status = 'PENDING' THEN 'Position Request Initiated'
    IF wfRequestNav.wfRequestSteps.stepNum = [Manager Approval Step Number] AND wfRequestNav.wfRequestSteps.status = 'APPROVED' THEN 'Position Request Approved by Manager'
    IF wfRequestNav.wfRequestSteps.stepNum = [HR Approval Step Number] AND wfRequestNav.wfRequestSteps.status = 'APPROVED' THEN 'Position Request Approved by HR'
    IF wfRequestNav.wfRequestSteps.stepNum = [Budget Approval Step Number] AND wfRequestNav.wfRequestSteps.status = 'APPROVED' THEN 'Position Budget Approved'
    IF wfRequestNav.wfRequestSteps.status = 'REJECTED' THEN 'Position Request Rejected'
    ELSE null
  EventTime = wfRequestNav.wfRequestSteps.completedOn
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = wfRequestNav.wfRequestSteps.completedOn
  UserId = wfRequestNav.wfRequestSteps.processedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = wfRequestNav.wfRequestSteps.approverId
FILTERS:
  ActivityName IS NOT null
  wfRequestNav.wfRequestSteps.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 3: Position Activated
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Activated' (Fixed Value)
  EventTime = Position.effectiveStartDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.effectiveStartDate
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  Position.status = 'A' (Active)
  // This requires an advanced filter to check the status of the previous record, which can be complex in Integration Center.
  Position.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 4: Position Attributes Modified
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Attributes Modified' (Fixed Value)
  EventTime = Position.lastModifiedDateTime
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.lastModifiedDateTime
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  // This filter should exclude records that are purely status changes captured in other blocks.
  Position.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 5: Position Reclassified
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Reclassified' (Fixed Value)
  EventTime = Position.effectiveStartDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.effectiveStartDate
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  // Requires advanced filter to check if Position.jobCode has changed from the previous record.
  Position.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 6: Position Reviewed for Compliance
// This requires a custom MDF object or workflow configured by the customer.
ENTITY: Position -> cust_ComplianceReview.position
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Reviewed for Compliance' (Fixed Value)
  EventTime = cust_ComplianceReview.lastModifiedDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = cust_ComplianceReview.lastModifiedDate
  UserId = cust_ComplianceReview.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = cust_ComplianceReview.reviewerId
FILTERS:
  cust_ComplianceReview.lastModifiedDate >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 7: Position Frozen/Suspended
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Frozen/Suspended' (Fixed Value)
  EventTime = Position.effectiveStartDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.effectiveStartDate
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  Position.status = '[Your Frozen Status Code]'
  Position.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 8: Position Deactivated
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Deactivated' (Fixed Value)
  EventTime = Position.effectiveStartDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.effectiveStartDate
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  Position.status = 'I' (Inactive)
  Position.lastModifiedDateTime >= [Start Date]

-- UNION ALL (Configured by adding a sibling element)

// BLOCK 9: Position Closed
ENTITY: Position (Effective Dated History)
FIELDS:
  PositionId = Position.code
  ActivityName = 'Position Closed' (Fixed Value)
  EventTime = Position.effectiveStartDate
  SourceSystemId = '[Your SFTP Server Name]' (Fixed Value)
  LastDataUpdateTime = Current Execution Time (System Variable)
  EventEndTime = Position.effectiveStartDate
  UserId = Position.lastModifiedBy
  DepartmentName = Position.department.name
  PositionStatus = Position.status
  ApproverId = null (Fixed Value)
FILTERS:
  Position.status = '[Your Closed/Eliminated Status Code]'
  Position.lastModifiedDateTime >= [Start Date]

Steps

Prepare Python Environment: Ensure you have Python 3.6 or newer installed. Install the necessary libraries using pip: pip install requests pandas.
Configure API Access: Obtain API credentials for SAP SuccessFactors. This includes the API server URL, Company ID, and a username and password (or client ID and secret for OAuth 2.0) for a technical user. This user must have permissions to access the OData APIs for entities like Position, WfRequest, WfRequestStep, and related foundational objects.
Set Script Parameters: Open the provided Python script. Locate the configuration section at the top and replace the placeholder values for API_ENDPOINT, COMPANY_ID, API_USER, API_PASSWORD, and the desired START_DATE and END_DATE for the extraction period.
Customize Mappings: Review the STATUS_ACTIVITY_MAP and WORKFLOW_STEP_MAP dictionaries in the script. Adjust the keys (SuccessFactors status codes or workflow step names) and values (desired Activity Names) to match your organization's specific configuration in SuccessFactors.
Execute the Script: Run the script from your terminal using the command: python extract_position_management.py. The script will connect to the SuccessFactors API, fetch data for Positions and Workflows, and handle pagination automatically.
Data Processing: The script processes the raw API data in memory. It identifies creation events, status changes, modifications, and workflow steps, transforming them into a standardized event log format. Each distinct business event becomes a separate row.
Handle Custom Events: For the 'Position Reviewed for Compliance' activity, which is highly custom, locate the placeholder function get_compliance_review_events in the script. Implement the logic to query the relevant custom MDF object or workflow as per your system's configuration.
Review the Output: Once the script finishes, it will generate a CSV file named position_management_event_log.csv. This file contains the extracted event log.
Verify Data: Open the CSV file and perform validation checks as outlined in the validation steps. Ensure that the case count, activity distribution, and attribute completeness meet expectations.
Prepare for Upload: Ensure the CSV file headers match the ProcessMind data model requirements. The required columns PositionId, ActivityName, and EventTime must be present and correctly formatted. The file is now ready for upload into ProcessMind.

Configuration

API User Permissions: The technical user for the API must have read access to the following OData entities: Position, WfRequest, WfRequestStep, User, FODepartment, and any other entities required for attribute enrichment. Permissions should include OData API Position Export and OData API Workflow Export.
Date Range Filtering: The script uses a START_DATE and END_DATE to filter records based on their lastModifiedDateTime. For the initial load, a period of 12-24 months is recommended to capture complete lifecycles. For delta loads, use the timestamp of the last successful extraction as the new START_DATE.
Pagination: The script handles API pagination using the $top and $skip parameters. The PAGE_SIZE variable can be adjusted, but a value between 200 and 500 is generally optimal to balance performance and memory usage.
Entity Selection: The script primarily queries the Position and WfRequest entities. The $select parameter is used to limit the query to only the necessary fields, improving API performance.
Status and Workflow Mapping: The script contains dictionaries (STATUS_ACTIVITY_MAP, WORKFLOW_STEP_MAP) to map technical values from SuccessFactors (e.g., 'A' for Active status, 'WF_STEP_HR' for workflow step name) to business-friendly activity names. These must be configured to match your instance's setup.
Delta Logic: The script is designed for full loads within a date range. For recurring extractions, implement logic to manage delta records based on the LastDataUpdateTime to avoid processing duplicate data.

a Sample Query python

import requests
import pandas as pd
from datetime import datetime
import json

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your SuccessFactors API details
API_ENDPOINT = class="hl-string">"https://apiX.successfactors.com/odata/v2"
COMPANY_ID = class="hl-string">"[Your_Company_ID]"
API_USER = class="hl-string">"[Your_API_User]@[Your_Company_ID]"
API_PASSWORD = class="hl-string">"[Your_API_Password]"

class=class="hl-string">"hl-comment"># Date range for extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># Pagination size
PAGE_SIZE = 500

class=class="hl-string">"hl-comment"># Mappings (Customize to your SF configuration)
STATUS_ACTIVITY_MAP = {
    class="hl-string">'A': class="hl-string">'Position Activated',
    class="hl-string">'I': class="hl-string">'Position Deactivated',
    class="hl-string">'S': class="hl-string">'Position Frozen/Suspended',
    class="hl-string">'E': class="hl-string">'Position Closed',
    class="hl-string">'F': class="hl-string">'Position Frozen/Suspended'
}

class=class="hl-string">"hl-comment"># Note: Workflow step names can be found in WF_REQUEST_STEP.step_name
WORKFLOW_STEP_MAP = {
    class="hl-string">'Manager Approval': class="hl-string">'Position Request Approved by Manager',
    class="hl-string">'HR Approval': class="hl-string">'Position Request Approved by HR',
    class="hl-string">'Budget Approval': class="hl-string">'Position Budget Approved'
}

class=class="hl-string">"hl-comment"># --- Helper Functions ---
def fetch_sf_data(entity, select_fields, filter_query):
    class="hl-string">"""Fetches paginated data from a SuccessFactors OData entity."""
    all_records = []
    skip = 0
    while True:
        url = fclass="hl-string">"{API_ENDPOINT}/{entity}?$format=json&$top={PAGE_SIZE}&$skip={skip}"
        if select_fields:
            url += fclass="hl-string">"&$select={','.join(select_fields)}"
        if filter_query:
            url += fclass="hl-string">"&$filter={filter_query}"
        
        print(fclass="hl-string">"Fetching {entity} data, page starting at record {skip}...")
        response = requests.get(url, auth=(API_USER, API_PASSWORD))
        if response.status_code != 200:
            print(fclass="hl-string">"Error fetching {entity}: {response.status_code} {response.text}")
            break

        data = response.json()[class="hl-string">'d'][class="hl-string">'results']
        if not data:
            break

        all_records.extend(data)
        skip += PAGE_SIZE

    return all_records

def parse_sf_timestamp(sf_date):
    class="hl-string">"""Parses SuccessFactors OData timestamp format /Date(...)/."""
    if not sf_date:
        return None
    try:
        class=class="hl-string">"hl-comment"># Extract timestamp in milliseconds and convert to datetime
        ts = int(sf_date.split(class="hl-string">'(')[1].split(class="hl-string">')')[0])
        return datetime.fromtimestamp(ts / 1000)
    except (IndexError, ValueError):
        return None

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    events = []
    source_system_id = class="hl-string">"SAP SuccessFactors"
    last_data_update_time = datetime.now()

    class=class="hl-string">"hl-comment"># 1. Fetch Position history data
    position_filter = fclass="hl-string">"lastModifiedDateTime ge datetime'{START_DATE}T00:00:00Z' and lastModifiedDateTime le datetime'{END_DATE}T23:59:59Z'"
    position_fields = [class="hl-string">"code", class="hl-string">"effectiveStartDate", class="hl-string">"status", class="hl-string">"jobCode", class="hl-string">"lastModifiedBy", class="hl-string">"lastModifiedDateTime", class="hl-string">"createdBy", class="hl-string">"createdDateTime", class="hl-string">"departmentNav/name"]
    positions_raw = fetch_sf_data(class="hl-string">"Position", position_fields, position_filter)

    class=class="hl-string">"hl-comment"># Group by position code to process history
    positions_by_code = {}
    for pos in positions_raw:
        code = pos.get(class="hl-string">'code')
        if code not in positions_by_code:
            positions_by_code[code] = []
        positions_by_code[code].append(pos)

    class=class="hl-string">"hl-comment"># Process Position history for events
    for pos_id, history in positions_by_code.items():
        class=class="hl-string">"hl-comment"># Sort records by effective date and last modified date to establish order
        history.sort(key=lambda x: (parse_sf_timestamp(x[class="hl-string">'createdDateTime']), parse_sf_timestamp(x[class="hl-string">'lastModifiedDateTime'])))

        class=class="hl-string">"hl-comment"># Event: Position Created in HR System
        creation_record = history[0]
        events.append({
            class="hl-string">'PositionId': pos_id,
            class="hl-string">'ActivityName': class="hl-string">'Position Created in HR System',
            class="hl-string">'EventTime': parse_sf_timestamp(creation_record[class="hl-string">'createdDateTime']),
            class="hl-string">'UserId': creation_record.get(class="hl-string">'createdBy'),
            class="hl-string">'DepartmentName': creation_record.get(class="hl-string">'departmentNav', {}).get(class="hl-string">'name'),
            class="hl-string">'PositionStatus': creation_record.get(class="hl-string">'status'),
            class="hl-string">'ApproverId': None
        })
        
        last_status = creation_record.get(class="hl-string">'status')
        last_job_code = creation_record.get(class="hl-string">'jobCode')

        for i in range(len(history)):
            record = history[i]
            event_time = parse_sf_timestamp(record[class="hl-string">'lastModifiedDateTime'])
            department = record.get(class="hl-string">'departmentNav', {}).get(class="hl-string">'name')

            class=class="hl-string">"hl-comment"># Events from status changes (Activated, Deactivated, Frozen, Closed)
            current_status = record.get(class="hl-string">'status')
            if current_status != last_status and current_status in STATUS_ACTIVITY_MAP:
                events.append({
                    class="hl-string">'PositionId': pos_id,
                    class="hl-string">'ActivityName': STATUS_ACTIVITY_MAP[current_status],
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'UserId': record.get(class="hl-string">'lastModifiedBy'),
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'PositionStatus': current_status,
                    class="hl-string">'ApproverId': None
                })
            last_status = current_status

            class=class="hl-string">"hl-comment"># Event: Position Reclassified (Job Code changed)
            current_job_code = record.get(class="hl-string">'jobCode')
            if current_job_code != last_job_code and i > 0: class=class="hl-string">"hl-comment"># Avoid flagging on creation
                events.append({
                    class="hl-string">'PositionId': pos_id,
                    class="hl-string">'ActivityName': class="hl-string">'Position Reclassified',
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'UserId': record.get(class="hl-string">'lastModifiedBy'),
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'PositionStatus': current_status,
                    class="hl-string">'ApproverId': None
                })
            last_job_code = current_job_code

            class=class="hl-string">"hl-comment"># Event: Position Attributes Modified (generic modification)
            if i > 0: class=class="hl-string">"hl-comment"># This fires for any modification after creation
                 events.append({
                    class="hl-string">'PositionId': pos_id,
                    class="hl-string">'ActivityName': class="hl-string">'Position Attributes Modified',
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'UserId': record.get(class="hl-string">'lastModifiedBy'),
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'PositionStatus': current_status,
                    class="hl-string">'ApproverId': None
                })


    class=class="hl-string">"hl-comment"># 2. Fetch Workflow (WfRequest) data for position creations
    wf_filter = fclass="hl-string">"lastModifiedDateTime ge datetime'{START_DATE}T00:00:00Z' and (module eq 'POSITION' or objectType eq 'Position')"
    wf_fields = [class="hl-string">"wfRequestId", class="hl-string">"status", class="hl-string">"effectiveDate", class="hl-string">"createdBy", class="hl-string">"createdDate", class="hl-string">"wfRequestSteps/processedBy", class="hl-string">"wfRequestSteps/status", class="hl-string">"wfRequestSteps/createdDate", class="hl-string">"wfRequestSteps/stepName", class="hl-string">"objectKey"]
    wf_requests_raw = fetch_sf_data(class="hl-string">"WfRequest", wf_fields, wf_filter)

    for wf in wf_requests_raw:
        pos_id = wf.get(class="hl-string">'objectKey')
        if not pos_id: continue

        class=class="hl-string">"hl-comment"># Event: Position Request Initiated
        events.append({
            class="hl-string">'PositionId': pos_id,
            class="hl-string">'ActivityName': class="hl-string">'Position Request Initiated',
            class="hl-string">'EventTime': parse_sf_timestamp(wf[class="hl-string">'createdDate']),
            class="hl-string">'UserId': wf.get(class="hl-string">'createdBy'),
            class="hl-string">'DepartmentName': None, class=class="hl-string">"hl-comment"># Department info is not in WfRequest
            class="hl-string">'PositionStatus': class="hl-string">'Pending',
            class="hl-string">'ApproverId': None
        })

        class=class="hl-string">"hl-comment"># Event: Position Request Rejected
        if wf[class="hl-string">'status'] == class="hl-string">'REJECTED':
            last_step = wf.get(class="hl-string">'wfRequestSteps', {}).get(class="hl-string">'results', [])[-1] if wf.get(class="hl-string">'wfRequestSteps') else {}
            events.append({
                class="hl-string">'PositionId': pos_id,
                class="hl-string">'ActivityName': class="hl-string">'Position Request Rejected',
                class="hl-string">'EventTime': parse_sf_timestamp(last_step.get(class="hl-string">'createdDate')),
                class="hl-string">'UserId': last_step.get(class="hl-string">'processedBy'),
                class="hl-string">'DepartmentName': None,
                class="hl-string">'PositionStatus': class="hl-string">'Rejected',
                class="hl-string">'ApproverId': last_step.get(class="hl-string">'processedBy')
            })

        class=class="hl-string">"hl-comment"># Events for approval steps
        if wf.get(class="hl-string">'wfRequestSteps') and class="hl-string">'results' in wf[class="hl-string">'wfRequestSteps']:
            for step in wf[class="hl-string">'wfRequestSteps'][class="hl-string">'results']:
                step_name = step.get(class="hl-string">'stepName', class="hl-string">'')
                if step[class="hl-string">'status'] == class="hl-string">'APPROVED' and step_name in WORKFLOW_STEP_MAP:
                    events.append({
                        class="hl-string">'PositionId': pos_id,
                        class="hl-string">'ActivityName': WORKFLOW_STEP_MAP[step_name],
                        class="hl-string">'EventTime': parse_sf_timestamp(step[class="hl-string">'createdDate']),
                        class="hl-string">'UserId': step.get(class="hl-string">'processedBy'),
                        class="hl-string">'DepartmentName': None,
                        class="hl-string">'PositionStatus': class="hl-string">'In Approval',
                        class="hl-string">'ApproverId': step.get(class="hl-string">'processedBy')
                    })

    class=class="hl-string">"hl-comment"># 3. Placeholder for class="hl-string">'Position Reviewed for Compliance'
    class=class="hl-string">"hl-comment"># This event is highly customer-specific. You need to implement the logic here.
    class=class="hl-string">"hl-comment"># Example: Query a custom MDF object or a specific workflow type.
    class=class="hl-string">"hl-comment"># compliance_events = get_compliance_review_events(START_DATE, END_DATE)
    class=class="hl-string">"hl-comment"># events.extend(compliance_events)

    class=class="hl-string">"hl-comment"># --- Final Dataframe Creation ---
    if not events:
        print(class="hl-string">"No events found for the specified period.")
        return

    df = pd.DataFrame(events)

    class=class="hl-string">"hl-comment"># Add standard columns
    df[class="hl-string">'SourceSystemId'] = source_system_id
    df[class="hl-string">'LastDataUpdateTime'] = last_data_update_time
    df[class="hl-string">'EventEndTime'] = df[class="hl-string">'EventTime'] class=class="hl-string">"hl-comment"># For atomic events, end time is the same as start time

    class=class="hl-string">"hl-comment"># Standardize column names and order
    final_columns = [
        class="hl-string">'PositionId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EventEndTime', class="hl-string">'UserId',
        class="hl-string">'DepartmentName', class="hl-string">'PositionStatus', class="hl-string">'ApproverId', class="hl-string">'SourceSystemId', class="hl-string">'LastDataUpdateTime'
    ]
    df = df.reindex(columns=final_columns)

    class=class="hl-string">"hl-comment"># Clean up and save
    df.dropna(subset=[class="hl-string">'PositionId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    df.sort_values(by=[class="hl-string">'PositionId', class="hl-string">'EventTime'], inplace=True)

    output_filename = class="hl-string">'position_management_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Event log successfully created: {output_filename}")

if __name__ == class="hl-string">'__main__':
    main()

Your Hire to Retire - Position Management Data Template

Your Hire to Retire - Position Management Data Template

Hire to Retire - Position Management Attributes

Hire to Retire - Position Management Activities

Extraction Guides

SuccessFactors Integration Center Outbound Export

Steps

Configuration

a Sample Query config

SuccessFactors Report Center Canvas Report Export

Steps

Configuration

a Sample Query config

Python Script Extraction via SuccessFactors OData API

Steps

Configuration

a Sample Query python

Ready to Get Started?

Boost Efficiency in Hire to Retire Position Management Today!

Your Hire to Retire - Position Management Data Template

Your Hire to Retire - Position Management Data Template

Hire to Retire - Position Management Attributes

Hire to Retire - Position Management Activities

Extraction Guides

SuccessFactors Integration Center Outbound Export

Steps

Configuration

a Sample Query config

SuccessFactors Report Center Canvas Report Export

Steps

Configuration

a Sample Query config

Python Script Extraction via SuccessFactors OData API

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Boost Efficiency in Hire to Retire Position Management Today!