Modelling best practices

Object or not:

While you are working to get your processes set up in konekti, you might come across something where you ask yourself should this be an object? We will offer some advice for such situations. An item should generally be an object if the item is part of the process you are following with its own events.

When to use attribute

If an additional piece of information is something that has meaning by itself, then it should likely be an attribute.
If you want to use multiple pieces of information that are related and you use those more than once, then you might want to consider to create an object for those, for example product number, price, location could become Object Products instead of attributes for store and invoice line. We don't advise you to add attributes that are calculated based on other attributes, these can be calculated at a later step in your process mining tool instead.

When to add object to object relationships

Relationships between objects should be kept to necessary relationships only. Every relationship should have a function, for example creating a meaningfull visualisation, or answering a business question.

Best Practices for Process Data Modeling in Konekti

1. Object vs. Attribute

Model as an Object if:

• The entity has a lifecycle with meaningful status changes (e.g. created, updated, completed).
• It participates in multiple events over time.
• It is referenced in multiple processes.
• You intend to analyze or filter based on this entity across use cases.

Examples:
Order, Invoice, Customer, Ticket

Model as an Attribute if:

• The value is descriptive or contextual, not independently actionable.
• It does not change independently of its parent object.
• It is not reused across processes or models.

Examples:
Customer type, Order amount, Invoice due date

---

2. Activity vs. Attribute

Model as an Activity if:

• The element represents a timestamped change or business action.
• It impacts process flow, duration, or decision points.
• It is important for auditing, monitoring, or compliance.

Examples:
Submit Order, Approve Invoice, Send Email, Create Ticket

Model as an Attribute if:

• The value describes the event but is not the event itself.
• It represents a parameter, channel, or metadata of the activity.

Examples:
Approval method, Email recipient, Ticket category

---

3. Relating Objects to Each Other

Relate objects when:

• They co-occur in an event (e.g. Invoice linked to Order).
• One object logically references another across processes.
• You want to enable multiple case perspectives from a single data model.

Example:
Invoice → relates to → Order

Note: Use object relations instead of copying logic between models.

---

4. Relating Activities to Objects

An activity should relate to:

• The object whose lifecycle it changes.
• The object most relevant for measuring performance or analysis.
• The entity that best encapsulates the meaning of the activity.

Example:
Approve Invoice → relates to → Invoice
Assign Agent → relates to → Ticket

Guideline: If the activity would not occur without the object, link it there.

---

5. Separate Objects vs. Multi-Meaning Objects

Use separate objects when:

• Each object has a distinct business role or lifecycle.
• Different stakeholders own or manage the data separately.
• You want modularity or support for diverse use cases.

Example:
Order and Return as separate objects

Use multi-meaning objects only if:

• The object role does not affect behavior or analysis.
• Variants can be handled with attributes.
• Separation adds unnecessary complexity.

Example:
User with attribute User type = “Customer” / “Employee”

---

6. Naming Conventions

Object Naming

• Use singular nouns.
• Keep it short, descriptive, and unambiguous.
• Avoid system-specific codes or acronyms.

Examples:
Invoice, Order, Customer, Delivery

Activity Naming

• Use a Verb + Noun pattern.
• Start with the action.
• Use business terminology, not technical.

Examples:
Send Invoice, Create Order, Review Ticket, Close Case

Bad Examples:
Invoice Sent, Order Created, Ticket Review (too passive or unclear)

---

7. Principles Summary Table

Modeling Decision	Best Practice
Entity with lifecycle	Model as Object
Static or descriptive data	Model as Attribute
Timestamped action	Model as Activity
Activity context/parameter	Model as Attribute
Reused across processes	Define as Object
One-off data point	Define as Attribute
Events affect object lifecycle	Relate Activity to Object
Objects co-occur	Create Relation between Objects
Different business meanings	Separate Objects
Shared but static meaning	One Object, Attribute for type
Object Name	Singular, concise noun
Activity Name	Verb + Noun, use business language