Tuesday, August 6

Integrations - Reports and Tasks

Integrations - Reports and Tasks


Some of the most Frequently used Reports and Tasks in Integrations are listed below :

Process Monitor
Create EIB
Edit EIB 

View ID Definition / Sequence Generator
Sequence Generator Padding Report

Scheduled Future Processes
Scheduled Future Processes
Mass Extend Scheduled Future Processes

Bulk Recover Scheduled Future Processes

All Integration Systems
Create Integration System
Clone Integration System
View Integration System
Launch / Schedule Integration
Integration Events

Integration IDs
Integration Messages
Audit Trail - Integration

Scheduled Future Reports Exception Audit
Scheduled Future EIBs Exception Audit

Integration Exception Audit
Configure Integration Delivery for Current Environment

View Integration Tags
View Integration Document Option

For below replace Create with View / Edit / Delete :

Create Integration Custom Object Service
Create Integration Delivery Service
Create Integration Enumeration Definition
Create Integration Field Attributes Service
Create Integration Field Override Service
Create Integration Generic Service
Create Integration Listener Service
Create Integration Notification Condition Rule
Create Integration Report Service
Create Integration Retrieval Service
Create Integration Sequence Generator Service
Create Integration Service Attachment
Create Integration Transaction Log Service
Create Integration Attachment
Create XSLT Attachment Transformation

Tuesday, July 30

Workday Feature - Sitemap

Sitemap


Sitemap means list of pages in a website. Consider Workday as a website and here to you have different pages, those pages we call it as Reports and Tasks.

Along with the Search option in Workday, we have Sitemap which lists out all the Reports and Tasks related to different modules / categories.

Below snapshot shows how a Sitemap looks like. On the Left hand side you will notice the categories and the respective Reports and Tasks.

You could be able to download to Excel sheet or PDF - but Just the Categories and not the reports and tasks.


Workday Sitemap

Points to Ponder:
  • Your list of Reports and Tasks are shown based on the security that you are provided with.
  • All the list of Reports and Tasks that you see on sitemap can be searchable in the search bar.

Friday, July 26

Related Terms and Glossary - Security

Security Terms


Security Groups -
A collection of system users used to grant access to Workday. Security Groups are added to security policies to give members permissions to secured items in Workday. Group of users who need to perform actions or access data

Domain Security Policy-
Rules that dictate which security group can view or modify data within the domains

Components of Configurable Security:

  • Security Groups
  • Domains
  • Domain Security Policies
  • Business Processes
  • Business Process Security Policies

What are the 3 types of security constraints?

  • Unconstrained: members have access to available data instances
  • Constrained: members will only have access to data for assigned constraints
  • Mixed: Members have a mix of constrained and unconstrained

User-based security groups-
These groups are assigned manually to individual users to grant tenant wide access in Workday. Usually intended for administrators that needs system wide access.

Two types of Security Policies-
Domain security policies and Business process security policies.

Domain-
Domains are a collection of items that share the same security, including:
- Tasks
- Reports and report fields
- Web service operations

Domain Security Policies control which security groups have access to data in the domain
- View Security for Securable Item Report

Functional Area-
Represent the main grouping of delivered domains and BP types. These groupings are typically for a specific module or area of Workday, such as Procurement, Integrations, or Personal Data. Functional areas can be enabled or disabled.

Functional Area Report-
Functional Areas report is a "top-down" report which allows you to see a top-down view of Workday functional areas and the domains and business process types in each

Business Process Security Processes-
Business Processes Security Policies control which security groups can participate in the business process (initiate, perform actions, approve, cancel, delegate, etc.)
Have to give permission for multiple policies (ex. Approve, review, etc.)
Each business process type has a single security policy that secures all business process definitions of its type

Steps for Configuring Security:
1. Identify users- who needs access to what?
2. Create security groups- identify existing security group or create a new one for your employees
3. Edit Security Policies- grand view/ modify permissions to domains or grant business process permissions (sometimes domain OR business process or sometimes combo of both)
4.Activate Pending Changes to take effect
5. Test Changes to verify changes made provide the expected access (for both those who got access and those who don't need access)

Workday-Assigned Security Groups
These Security Groups grant GENERAL access and are AUTOMATICALLY assigned by the Workday system
- Assigned to a person
- Based on process such as hiring/ terminating
Ex. Employee as self, worker, all employees, all users, manager's manager

User-Based Security Groups-
These Security Groups grant ADMINISTRATIVE access tenant wide- typically for maintenance/admin groups
- Responsibility applies throughout the system (not just supervisory orgs but for entire tenant)
- User-based security groups are manually assigned to a worker
- Multiple people can be members of the same user-based security group
○ Ex. Benefits admin, compensation admin, payroll admin, report writer, HR admin, etc.

Steps for Creating a User-Based Security Group:
1. Create user-based security group
2. Configure security group on security policies
3. Activate pending security policies
4. Assign users to security group
5. Test (user can create an exit interview, testing it on who should be able vs who should not)
*Don't forget to add group for "administered for security groups" like Security Administrator, otherwise they wont be able to access anything

Role-Based Security Groups:
These Security Groups help identify your support or leadership staff
- Membership is derived based on being assigned an organizational role
- Roles are assigned to organizations (or location hierarchies)
- Roles are assigned to positions, NOT workers
- Roles inherit from superior org if not filled (if configured to do so)
- Access can be defined as constrained and unconstrained

Steps for Creating a Role-Based Security Group:
1. Use "maintain assignable roles" to create or modify assignable roles (supplemental book page 34-35)
2. Create role-based security group
3. Configure security group on security policies
4. Activate security policy changes
5. Assign roles to jobs/ positions to organizations
Test

Job-Based Security Group:
Identify members based on a job criterion

  • Job profile
  • Job category
  • Job family
  • Management level
  • Work shift
  • Include exempt jobs
  • Include non-exempt jobs

Automatic membership, Can be constrained or unconstrained

Membership-Based Security Groups:
     1. Location (meant for more specific location, not US as a whole)
            Grants access to a task based on the location for a worker
            Once created, automatically assigned based on users location
 Example: for initial deployment of time tracking, only London workers enter time on Workday

     2. Organization
             Grants access to a task based on the user's membership in org
             Once created, automatically assigned based on organization assignments
Example: business unit, company, cost center, pay group, USA as a whole, etc.

Combination Security Groups:
    1. Intersection -
            Grants access based on membership in ALL of the included security groups
            Includes only users who meet all of the specifications
    2. Aggregation Security Group -
            Includes users who are in ANY of the selected security groups
            User does not have to be in every included group

Security Domain
A predefined set of related securable items that include reports, tasks, report fields, data sources, and data source filters
- The securable item that make up a domain cannot be changed
- Each domain has its own security policy that controls access to the security items

Which security group is assigned directly to a worker?
User based security-Tenant wide

Role based security group permissions are given to a worker when their position is linked to what?
Support Role

Editing a security policy takes effect immediately
False- Need to activate

Business Process Policies-
Defines which security groups can participate in the business process

Security group that allows self service access?
Employee as self

Groups of users who need to perform actions or access data?
Security Groups

Thursday, July 25

Workday Business Objects

Workday Business Objects

Workday architecture is Object based. Workday stores the data in business objects (BO).
A business object is like a spreadsheet, where each row is an instance of the object. Each column represents an attribute, or field, of the object.

Example:  Workers John Anderson and Cathy Robins are each an instance of the Worker business object. The Worker business object contains fields such as Job Title, Age, Gender, and Dependents.

Below Snapshot shows how Business Objects are automatically connected. In the View 1, the Worker Business Object is linked to Benefits, Salary, Manager and Position. Which means the Worker is sitting in a Position, reporting to a Manager, getting some Salary and opted for Benefits.  In the View 2, Position is linked to Location and in turn Location is linked to Currency.  Here all of them are BO's.
Business Objects - Sample





















Workday links related business objects together through single instance or multi-instance fields. Related Business Objects (PBO) enable you to access fields in a report that don’t belong to the Primary Business Object. (RBO)

Example: The Worker business object has a multi-instance field called Dependents. Dependents has a related business object of Dependent. In a report with a primary business object of Worker, you can use the Dependents field to access the fields belonging to the Dependent business object.

A report by name Business Object Details can be used to view:
  • Custom and standard reports that use the business object.
  • Data sources using the business object as the primary business object.
  • Fields associated with the business object.
  • Related business objects.
If you want to relate the workday terms with Database Management Systems like Oracle, MySQL, SQL Server, see below:


Wednesday, July 24

Staffing Models in Workday

Staffing Models

Staffing Models tells you how jobs are defined and filled. Staffing models determine:
  • The level of control that can be placed on staffing
  • How workers, jobs and positions can be moved between supervisory organizations
  • Where hiring restrictions (aka criteria or eligibility) are set
There are Two staffing models in Workday: Position management and Job Management. There used to be Headcount Management in the earlier releases. But later this was deprecated.

Position Management
  • A position must be open to hire, transfer, promote, demote a full-time or contingent worker into an organization.
  • Separate hiring rules and restrictions for each position, 
  • Specify number of positions to fill before a worker can be hired, (max of 100 positions can be created at a time)
  • Positions can be closed if they are no longer needed
  • Provides greater control over hiring 
Think of a table with chairs, if the chair has a person in it it's a position and its filled, if no one sits there then its unfilled.

Job Management

  • Hiring restrictions apply to all jobs at the organizational level, Unlike in your Position Management you need to give definitive number of positions that you want to open.
  • No requirements to set limits on number or positions to be filled,
  • Workflow and approvals are used to control the number of workers and no ability to report on unfilled positions
Ex: Retail and seasonal jobs, Manufacturing occupations