• Brian Williams
  • NEWBIE
  • 0 Points
  • Member since 2011

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 0
    Questions
  • 2
    Replies
My company and I are new to SalesForce and we are attempting to convert all of our current legacy support data into SalesForce/SupportForce.  Part of this legacy data consists of "cases" that are associated with users (owners) and members (contacts). 

I have imported/created a subset of the users and and contacts that I need in order to get a sample set of data into SalesForce.  Since many of the users/owners are no longer employeed by us, I created SalesForce user accounts and tagged tham as Inactive so that I can maintain all of the current relationships (since we do not have enough licenses in order to get ALL of the users in our current system into SalesForce as active users).

I am now trying to insert a series of cases using the data loader and associate them via contactid and ownerid. 

The problem that I am having is that when I attempt to insert the records using the data loader, the records associated with inactive users are failing to upload with the following error: "operation performed with inactive user."

Is there a way to insert case records and associate them with a inactive user?  I assume that this happens frequently as people export and re-import their data for various reasons.

BTW, I have also tried creating lookup relations between the Case record and User and Contact, but those attempts always failed due to not having a valid ID type needed for the relation (I tried using both Integer and Real values - i.e. 1 and 1.0)

Thanks in advance.

If you try to create a standard object record (account, contact etc..) specifying an inactive ownerId, the API complains loudly and the record is rejected. This is fair enough.

If you try to create a custom object record specifying an inactive ownerId, then the API happily creates the record returning an ID. I would prefer it to complain and reject the record.

Is this a subtle design feature of API 4.0?