Create a Subject
Learn how to create and configure a subject.
A subject is an entity that changes over time, for example, employees, applicants, requisitions, learning items, and sales opportunities.
For guidelines about whether a subject is the right object type to create, see Should I create a subject? For a tutorial that walks you through creating a subject, see Create a Subject to Analyze Expense Report Data.
Create a subject
Access requirements
Profiles: Advanced Model Developer
Custom profile with these capabilities: Model (Write, Detailed) and Extend Data Model
Reach out to your administrator for access.
You can create up to 2,500 subjects per project. These maximums are the default, however, contact Visier Technical Support to request limit adjustments.
- In a project, on the navigation bar, click Model > Analytic Objects.
- Click Create Analytic Object.
- In Analytic object type, select Subject.
- Type a display name and description.
- When finished, click Create.
Configure a subject
Configure a subject by creating properties, defining the list of properties displayed in the Detailed View visual, changing the subject's settings, and more.
Access requirements
- Basic Model Developer
- Advanced Model Developer required for Settings, References, and Suggested Key Groups configurations
Custom profiles with one of the following capability sets:
- Model (Write, Simple)
- Model (Write, Detailed) required for Settings, References, and Suggested Key Groups configurations
Reach out to your administrator for access.
- In a project, on the navigation bar, click Model > Analytic Objects.
- Select a subject.
- In Attributes, create attributes to hold specific data for the object. For more information, see Properties, Dimensions, and Concepts.
- In Settings, define the object's settings. For more information, see Subject settings below.
- Optional: Do any of the following configurations:
- In References, add references to other objects. For more information, see References.
- In Suggested Key Groups, add key groups to suggest to users for the object. For more information, see Key groups (optional).
- In View Details, add properties to display in the Detailed View visual. For more information, see Configure View Details.
- In AI Configuration, manage the properties used in AI calculations for the object. For more information, see Configure AI Attributes.
- In Basic Information, change the display name, description, and explanation of the object. For more information, see Change the Display Name, Description, or Explanation of a Visier Object.
View example
Example: Employee
Let's say you want to configure a new subject called Employee. This subject represents employees in your organization. To set up Employee, you would make the following configurations:
- Attributes: Create attributes that are essential for analysis, such as Career Level, Critical Employee, Current Employee, Employment Type, First Name, Full Name, Gender, High Performer, Job Name, Last Name, Location Hierarchy, Manager, Organization Hierarchy, Performance Rating, and Tenure.
- Settings: Configure the following settings.
- Tags: Organization. This identifies Employee as part of the Organization content category.
- Events: Conception Event = Employment Start and Termination Event = Employee Exit. This indicates that Employment Start events indicate a new employee's start with the organization and Employee Exit events indicate an employee's exit from the organization.
- Captions: Instance Captions = Full Name and Secondary Captions = Job Name. This allows you to see an employee's full name and job name in Detailed View and Compare.
- Primary key dimension: Enabled. This allows you to group by Full Name.
- Large dimension search: Disabled. This prevents you from searching by Full Name (the caption) if it has more than 300,000 members.
- Data version settings: Disabled. This ensures that Employee uses the default settings defined in the data version settings.
- Default metric: Headcount. This means that if a user tries to analyze Employee, the default metric displayed in a visualization is Headcount.
- Data category: Tenant. This means that Employee data is loaded through the Tenant data category. For more information, see Data Categories.
- References: Create a forward reference to Direct Manager. This allows you to connect employee data to direct managers.
- Suggested Key Groups: Add key groups to suggest to users, such as High Performer, Manager, and Critical Employees. These key groups will be suggested as group bys when users interact with Employee data in visualizations.
- View Details: Add properties that you want to appear in the Detailed View visual, such as Critical Employees, High Performer, and Manager. These properties will be visible to users in Detailed View.
- AI Configuration: Configure the following settings.
- Properties: Gender, Tenure, Manager Status, Job Name, and Performance Rating. These are the default properties to use in AI calculations.
- Change Properties: Manager Status, Performance Rating, Job Name. These are the default properties related to change to use in AI calculations.
- Grouping Dimensions: Gender, Manager Status, Job Name. These are the default dimensions to use in AI calculations.
- Basic Information: If Description is blank, add "Current employees of the organization.".
Subject settings
The subject settings allow you to modify its default metric, the subject's conception and termination events, and more.
Access requirements
Profiles:Advanced Model Developer
Custom profile with these capabilities:Model (Write, Detailed)
Reach out to your administrator for access.
Tags
Tags are user-defined categories that group content in the solution. A tag can apply to multiple object types, including analytic objects, metrics, and guidebooks. A user may filter for objects with a particular tag throughout the solution. For this setting, add tags to identify the object as part of a specific content category. For more information about tags, see Create and Assign Tags to Content.
Example:
The Compensation tag is used for the Pay Change Events metric, the Total Cost of Workforce concept, the Compensation Type dimension, and the Compensation Payout event. This tag therefore groups these objects together as relating to compensation. The Compensation tag itself is allocated to the Talent module, meaning it exists within that solution.
Events
Events represent an incident at a specific point in time that occurs to a subject. They have attributes, but an event does not change after it has occurred. For this setting, select the conception and termination events for the subject. These events define the validity interval for a subject. Some subjects do not require conception and termination events.
Example:
The Employee subject has the conception event Employee Start and the termination event Employee Exit. The conception event indicates that the employee has started with the organization and is active, while the termination event indicates the employee is no longer with the organization and isn't active.
Captions
Captions help the user identify a subject member or event occurrence. Use an instance caption to label members or occurrences by their property values; use a secondary caption for additional identification.
If a caption is set, it:
- Displays the property in the Detailed View visual. For example, if Employee's caption is Full Name and secondary caption is Job Name, Detailed View will display Jane Smith, HR Specialist.
- Makes the subject available in the Compare room.
Example:
The property Full Name identifies specific employees. However, this may be an insufficient caption as employees sometimes have the same name, like John Smith. A secondary caption, such as Role or Location, further identifies particular employees.
Watch this video to learn how to change your captions.
Primary key dimension
The primary key dimension determines whether the unique values for the subject can be used as a group by or filter in a visualization. To configure the primary key dimension, choose one of the following options:
- On: Expose the analytic object's primary key or caption for grouping and filtering subject members. If a caption is not set, this toggle determines whether the subject's primary key, for example, Employee ID, can be used as a group by and filter. If a caption is set, this toggle determines whether the subject's caption can be used as a group by and filter. This is used in conjunction with Captions to define a display name for the subject's primary key.
- Use existing dimension: Use an existing dimension to group and filter subject members.
- Off: Do not expose a dimension for grouping and filtering subject members.
Example: Employee
Let's say that Employee doesn't have a caption defined, but the primary key dimension toggle is enabled. In this scenario, the toggle allows Employee ID (Employee's primary key) to be used as a group by and filter in visualizations.
Alternatively, let's say that Employee's caption is Full Name and the primary key dimension toggle is enabled. In this scenario, the toggle allows Full Name (Employee's caption) to be used as a group by and filter in visualizations.
Example: Succession Candidate
Understanding your organization's succession readiness can be vital to continued productivity when turnover occurs. To visualize succession candidates as a group by, enable the primary key dimension toggle for the Succession Candidate subject.
Example: Skill
Since Skill Name is a shared dimension, enabling the primary key dimension toggle on the Skill subject results in duplicate hierarchies when used as a group by in visualizations. In this case, we can select Use existing dimension and select the Skill Name dimension on the Skill subject. This ensures the visualization only shows values from the dimension on the Skill subject.
Large dimension search
Allows dimension searching across all member values of the primary key dimension or caption, bypassing the default 300,000 upper bound limit of members. Only applicable when primary key dimension is enabled and the hierarchy has less than 20 million members.
Data version settings
Visier allows each analytic object to override the globally-defined end date.
The end date config type sets the upper limit of selectable time periods in the solution experience. For example, if the end date config type is End of previous month and the current month is February, your users can select data up to the end of January in analyses and visualizations.
You can set the end date config type at the tenant level and per analytic object.
- Tenant level: The end date config applies to all analytic objects.
- Per analytic object: Overrides the tenant end date config for a specific analytic object.
Example: Let's say you load Employee data on the 15th of every month, Applicant data every Wednesday, and Requisition data every Friday. In this example, Applicant and Requisition have new data every week, whereas Employee has new data once a month. We can set the tenant end date config type as End of previous week, and then set an end date override for Employee as End of previous month. This allows your users to select dates up to the end of the previous week for Applicant and Requisition, and up to the end of the previous month for Employee. Without the Employee override, users could select dates for Employee up to the end of the previous week, but Employee data isn't loaded weekly so the visualizations would be blank.
To override the tenant end date config type for a specific analytic object:
- In a project, on the navigation bar, click Data > Tenant Settings.
- Select a data category.
-
In Settings, turn on Enable end date overrides on individual analytic objects.
Tip: If disabled, all analytic objects use the latest upload to determine the data end date. If enabled, each analytic object uses the latest upload for data that populate the object. For objects that aren't updated frequently, we recommend that you set object's end date config type to Use timestamp of source for a specific analytic object.
Let's say you loaded Employee Engagement data on July 31 and Employee data on September 20. Enable end date overrides on individual analytic objects is turned on, but there are no overrides for Employee Engagement or Employee specifically. Both objects use the tenant-level end date config type, but Employee Engagement uses July 31 as the latest upload, whereas Employee uses September 20 as the latest upload. If the tenant-level end date config type is End of previous month, then Employee Engagement's end date is June 30 and Employee's end date is August 31.
- On the navigation bar, navigate to Model > Analytic Objects.
- Select an analytic object.
- In Settings, under Data version settings, turn on Use default.
- In End date config type, select an end date config type from the list.
The following table describes each of the end date config types.
Each example in the table assumes today is June 29 and the last data processing job ran on June 9. The examples show the latest date you can select in an analysis for three upload scenarios: an upload on April 30, an upload on May 2, and an upload on June 9.
|
End date config type |
Description |
Example: Latest selectable date in analyses |
|---|---|---|
|
Auto detect from data |
Use the date of the latest data point in the upload, including dates in the future. For example, let's say the latest data point in each example upload is April 30, July 1, and June 30, respectively. We recommend Auto detect from data as the default tenant-level end date config type. |
|
|
End of current month |
Use the last day of the month of the latest upload. |
|
|
End of previous day |
Use the day before the latest upload. |
|
|
End of previous week |
Use the most recent Sunday before the latest upload. |
|
|
End of previous month |
Use the last day of the month before the latest upload. |
|
|
Use source timestamp |
Use the exact time of the latest upload. |
|
|
Use timestamp of source for a specific analytic object |
Use the exact time of the latest upload that contains the data for a specified analytic object. For example, use the time of the latest upload for Employee data. Let's say the latest Employee upload was on March 8. |
The end date is March 8 for all three example uploads because the latest Employee upload was March 8. |
|
Use timestamp of current run |
Use the current time as of when the loaded data version was generated. |
The end date is June 9 for all three example uploads because the last data version was generated on June 9. |
|
End of current day |
Use midnight at the end of the latest upload day. |
|
|
End of previous month (if first load of month) or previous day |
Use the last day of the previous month if the upload is the first of the month. Otherwise, use the day before the upload. For example, let's say that April 30 isn't the first upload of the month, May 2 is the first upload of the month, and June 9 isn't the first upload of the month. |
|
|
End of previous month (if first load of month) or week |
Use the last day of the previous month if the upload is the first of the month. Otherwise, use the end of the previous week. For example, let's say that April 30 isn't the first upload of the month, May 2 is the first upload of the month, and June 9 isn't the first upload of the month. |
|
|
End of previous month (if first load of month) or use source timestamp |
Use the last day of the previous month if the upload is the first of the month. Otherwise, use the exact time of the latest upload. For example, let's say that April 30 isn't the first upload of the month, May 2 is the first upload of the month, and June 9 isn't the first upload of the month. |
|
|
End of current month (if last day) or previous month |
Use the last day of the current month if the upload happens on the last day of the month. Otherwise, use the last day of the previous month. |
|
|
End of previous month (if first load of month) or current month |
Use the last day of the previous month if the upload is the first of the month. Otherwise, use the last day of the current month. For example, let's say that April 30 isn't the first upload of the month, May 2 is the first upload of the month, and June 9 isn't the first upload of the month. |
|
|
Allow future data |
Use the furthest date in the upload. For example, let's say there is a future start date of July 1 in all example uploads. Caution: Do not use for subject and overlay data. |
The end date is July 1 for all three example uploads because a future start date of July 1 exists in each upload. |
|
Last specified day of the week |
Use the most recent specified weekday before the latest upload, such as the latest Wednesday. |
|
|
Later or last specified day of the week or end of previous month |
Use the most recent specified weekday before the upload without going beyond the previous month, such as the latest Wednesday. |
|
|
End of current month (if within five business days to end) or previous month |
Use the last day of the current month if the upload falls within five business days of month end. Otherwise, use the last day of the previous month. |
|
|
End of previous month (if first load of month) or last specified day of the week |
Use the last day of the previous month if the upload is the first of the month. Otherwise, use the most recent specified weekday, such as the latest Wednesday. In this example, let's say that April 30 isn't the first upload of the month, May 2 is the first upload of the month, and June 9 isn't the first upload of the month. |
|
The following groups show how each end date config type determines its result. For the exact behavior and examples, see the table above.
Use the exact moment of upload
- Use source timestamp: Exact time the upload happened.
- Use timestamp of current run: Exact time the data version was generated. This is not necessarily the upload time.
- End of current day: Midnight at the end of the upload day.
- End of previous day: Day before the upload.
Use a calendar boundary near the upload
- End of previous week: Most recent Sunday on or before the upload.
- End of current month: Last day of the upload's month.
- End of previous month: Last day of the month before the upload.
- Last specified day of the week: Most recent chosen weekday (e.g., latest Wednesday) before the upload.
Use the data, not the upload date
- Auto detect from data: The latest date actually found in the file, even future-dated. We recommend this as the default tenant-level end date config type.
- Allow future data: Same as Auto detect from data, but explicitly permits dates that haven't happened yet. Don't use this for subject and overlay data.
- Use timestamp of source for a specific analytic object: Borrow another object's upload schedule instead of this object's upload schedule.
Use special handling for the first upload of the month
If the upload is the first of the month, these options use the last day of the previous month. For any other upload, each falls back to its standard behavior.
- End of previous month (if first load of month) or previous day
- End of previous month (if first load of month) or week
- End of previous month (if first load of month) or use source timestamp
- End of previous month (if first load of month) or current month
- End of previous month (if first load of month) or last specified day of the week
Use special handling near the end of the month
- End of current month (if last day) or previous month: Only counts as current month if the upload literally lands on the last day.
- End of current month (if within 5 business days) or previous month: Counts as current month if the upload is within 5 business days of the last day of the month.
- Later or last specified day of the week or end of previous month: Weekday cutoff, but never earlier than the prior month.
Default metric
The default metric associated with an analytic object is used to generate system alerts and prevent an empty state for charts when your users switch between dimensions that have no relationship to the metric.
If enabled on a subject, default metric allows you to view the subject's history in Detailed View.
After onboarding data, the default metric is an easy way to quickly verify that the data for an object was loaded as intended. For this setting, select a metric that will act as the default metric for the object in visualizations and will be available as a data overview in Studio dashboard.
Example:
The Employee subject's default metric is Headcount. Because Headcount is a default metric for Employee, the system generates an alert for Headcount to ensure its values remain consistent and expected. When new employee data is loaded, the Headcount metric can be viewed in the dashboard as a quick way to discern if the data is accurate.
Data category
A data category represents a dataset loaded into Visier that runs on a unique data load frequency. For this setting, select the data category that you want to this analytic object and its data to be loaded in. In your tenant, you may see the following system-generated data categories:
- Tenant: This data category is the default primary data category.
- Usage: This data category processes Visier usage information.
Additionally, any data categories created by you or your Visier team are available to assign to the analytic object. For more information, see Data Categories.