cancel
Showing results for 
Search instead for 
Did you mean: 

Mandatory attributes and Convention checks in Signavio Process Manager

vp_nbn
Explorer
0 Kudos
212

Hi team and a happy New Year to everyone 🎆!

In our SAP Signavio Process Manager setup/ configuration, we have defined a number of main properties and custom attributes as mandatory, primarily at the diagram level. To enforce their usage, we’ve implemented a custom modeling convention. Section 2.2. of the convention (Definition of mandatory attributes) contains the rules for populating these mandatory attributes. Diagrams that violate modelling conventions (i.e. contain errors) cannot be published (to the Signavio Collaboration Hub)

For instance, in the screenshot provided you can see an example from our workspace. The diagram-level attribute Publisher is not populated, which triggers an error when the Convention check is triggered.

I’m curious to know your practice in this regard.

  1. Do you apply a separate rule for each attribute, or do you cover multiple attributes with a single rule? Could you please share your rationale behind this choice?
  2. Have you received feedback from your modellers regarding the error messages, particularly their clarity in helping the modellers identify and rectify the errors?
  3. Over the years of using Signavio, have you changed your approach to enforcing mandatory attributes? If yes, what factors led to this change?

I eagerly await your response. Thank you for your time and consideration.

Kind regards,

 

Vladimir

View Entire Topic
Rahulalankar
Explorer

Hi Vladimir,

Wishing you and your team a very Happy New Year! 🎉

Thank you for reaching out with such a detailed and thoughtful question about SAP Signavio Process Manager. It’s a great topic to discuss, and I’m happy to share how we’ve approached similar challenges.

1. How We Handle Rules for Mandatory Attributes

In our setup, we usually create separate rules for each mandatory attribute instead of grouping them together. While it might seem like extra work, this method has worked better for us because:

  • It’s clearer for modelers to know exactly which attribute is missing.
  • It gives us flexibility to tweak or remove rules as needed without affecting others.
  • It simplifies troubleshooting since each rule focuses on a single attribute.

That said, we occasionally combine related attributes (like diagram metadata) into a single rule when it makes sense, as long as it doesn’t compromise clarity for the team.


2. Feedback from Modelers on Error Messages

We’ve learned a lot from listening to our modelers about error messages. Here’s what’s worked well for us:

  • Being specific: Instead of vague errors, we make sure messages clearly state what’s missing and where (e.g., “The ‘Publisher’ attribute is missing in Diagram XYZ”).
  • Making it actionable: We include simple steps for resolving the issue. The goal is to make the error feel more like a helpful nudge than a roadblock.
  • Keeping it user-friendly: For teams that work in multiple languages, having error messages in their preferred language has made a big difference.

By focusing on clarity and guidance, we’ve been able to reduce frustration and speed up issue resolution.


3. How Our Approach Has Evolved Over Time

Yes, we’ve definitely changed how we enforce mandatory attributes over the years! Here’s why:

  • Modeler feedback: When team members shared what worked (and didn’t), we adjusted our conventions to better fit their needs.
  • Process growth: As our processes became more complex, we added new attributes while simplifying or removing others that weren’t as critical anymore.
  • Better tools: As Signavio introduced new features, we adopted them to make validations more efficient and less intrusive.
  • Team onboarding: We also realized that keeping things simple made it easier for new modelers to hit the ground running.

These changes weren’t always big, but they’ve made a meaningful difference in how smoothly things run.

I hope this gives you some useful insights into how we’ve tackled these challenges. The key for us has been balancing clear rules with flexibility, and always listening to the team for feedback.

If you’d like to dive deeper into any of this or compare notes, I’d be happy to chat more.

Br,
Rahul Aryan
Albatha Holdings LLC

vp_nbn
Explorer
0 Kudos

Thank you Rahul,

your response is highly appreciated.

My thinking was along similar lines so it's great to a confirmation. (I hope there is no confirmation bias here.)

I was wondering whether you could elaborate a bit more on how you include simple steps for resolving the issue to making Error messages actionable.

Kind regards,

Vladimir